I've spent the last few posts trying to model the OOPhoto domain and have found this to be extremely challenging. Aside from the fact that I am stepping foot in a world that is totally new to me, I think part of what has made it so difficult is that I cannot visualize the bigger picture. I find myself to be a very visual person, and if I can't "see" the solution, it is much harder for me to reach that solution. As such, I wanted to go over my existing understanding and all the great feedback that I have gotten and form a new understanding of how all the different layers of the Application relate to each other.
| || || |
| || |
| || || |
It's Friday night, so I am not going to try to think too hard about how much logic should go into each of those layers - I leave that for a more refreshed Ben. I know Brian Kotek said that I should avoid a "Fat" service layer; but, does that include things like Transaction control (CFTransaction) and object validation? I assume that I can have logic in the service layer so long as it primarily relies on invoking objects in the domain model.
Regardless, I think this graphic is a much better, more concrete visualization than what I had in my head prior. I think it also changes the way I want to approach my domain modeling. As Peter Bell suggested, I should be thinking about scenarios. I was trying to accomplish this by basing my growing model on the user interface; now, seeing that there is a common service layer to all access points of the application, I think I can shift my thinking to be more outside-in, rather than inside-out.
Looking For A New Job?
- ColdFusion Engineer at HotelPlanner
- ColdFusion Cloud Software Developer - SaaS Application at Retensa
By George, he's got it! ;-)
Sweeeeeet. Now, what I have to figure out - is the Service layer broken up into different objects? Or is it just one large API (like the front controller of a FuseBox application)?
Hmm if you mean can there be more than one Service layer object in an application? Absolutely. There might be a SecurityService, a UserService, a ReportService, etc. The idea is to break up the behavior that the model provides into common-sense groupings.
Sounds good. I think that this application is so small, that one service layer object should be fine. Something like a PhotoService, I suppose.