Layered Architecture vs Living Domain Model
Update: Fowler has blogged about this.
I just finished a great talk with Jon Tirsen, basically he points out that a layered architecture can get between you and your domain model.
We were discussing that the "small talk way" (i.e. the OO way) is to have a rich, living, useful domain model that does all the interesting things in your application.
If you have a layered architecture, you can end up having a service layer that seperates your client code (view or action) from your domain model.
Jon pointed out that having one of these layers, when you dont need one, is like burning $50 notes. You end up writing hundreds of lines of code in your service layer including marshalling and unmarshalling across the boundaries.
Another bad effect is that teams often end up implementing functionality as transaction scripts rather than in the domain where it belongs. The more you do this, the more anemic your domain model becomes, and the less useful your domain language becomes for solving problems in the future.
The advice from all this is that the one kind of appliction that does NOT need a layered architecture is a web application. Your views can and should have a rich and close collaboration with your domain code.
This conversation really got me thinking, is it actually possible to maintain a living domain model with a service layer in the way?
posted by Ben Hogan at 2:44 pm
7 Comments:
Jon sent me this comment: "[Doing it this way] you still have a layered architecture, ie: Operating System/Database/Web Server/Application/Browser. It's just that [the other way] it's layered in the wrong way, you create a distribution boundary in the middle of your app! where you don't need it. "
"is it actually possible to maintain a living domain model with a service layer in the way?"
Sure, a remote interface is not an excuse to neglect your domain model. You have to take special care to relegate you service logic to a thin facade over your domain layer that does nothing but adapt your domain model to the remote interface (i.e. no business logic).
Hi,
I am working on a new design pattern for my Bachelors thesis project. I would be grateful if you read this and let me know your views:
Distributed Command Pattern - an extension of command pattern for connected systems
http://www.codeproject.com/csharp/DistributedCommandPattern.asp
you create a distribution boundary in the middle of your app! where you don't need it.
This is the exact problem I have come across recently. A system using J2EE facades to split business and display layers. Hibernate objects which would normally load on demand, now must be fully pre-loaded before moving to the display tier.
The tier boundary is just an extra expense, especially when the business layer doesn't do too much, computationally. Quicker to leave it all in the one tier and use techniques such as Hibernate clustering to maintain state across the server array.
I guess what I'm saying is that a server array need not be a fully-fledged tier array.
Yo, you have a Terrific blog here! Lots of content means more readers, more readers means more interaction!
I'm definitely going to bookmark you!
I have a
window xpsite/blog. It pretty much covers window xp related stuff.
Come take a Look when you get a chance. :-)
Nice Site. We have Free Houses on my site. Please take a look home construction
Great blog!
Jon really has some good points here, I strongly agree with him.
I have earlier had a discussion with an architure dept. They insist in the many layered approach - maybe they will realize that I'm right now...
I have published a few articles about security and software architectures as well. They can be found at http://jessn.blogspot.com/
Post a Comment
<< Home