Skip to main content
Ben Nadel at cf.Objective() 2014 (Bloomington, MN) with: Matthew Orstad
Ben Nadel at cf.Objective() 2014 (Bloomington, MN) with: Matthew Orstad ( @rocketmidwest )

OOPhoto - Revisualizing The Application Layers

Published in Comments (4)

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.


OOPhoto - Revisualizing The Layers Of Application Development  

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



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.

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel