OOPhoto - Revisualizing The Application Layers
The latest OOPhoto application can be experienced here.
The latest OOPhoto code can be seen here.
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.
Reader Comments
By George, he's got it! ;-)
@Brian,
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.
@Brian,
Sounds good. I think that this application is so small, that one service layer object should be fine. Something like a PhotoService, I suppose.