Anemic Domain Model
I read an interesting post from my friend Ed at http://jroller.com/trackback/ewentworth/Weblog/is_the_anemic_domain_model. He responded to MF’s post on anemic domain model. I don’t think this is really about anemic domain model, instead it’s about separation of concerns. You can have objects with behavior that really belongs to those objects. However, some OO bigots stress on “Tell and don’t Ask” based behavior, which means instead of getters tell the object to what to do. This means that I can tell the object to save, print, etc. I think this is taking OO a bit too far. I wonder these people ever maintained a large enterprise system. In real system, separation of concerns or modularization means ease of maintenance and extensibility. I would not want to put persistence, printing or any other external capabilities to my domain objects, instead define them as a service.
As long as using business objects in service interfaces as opposed to DTO, I find that it does lead to simple services. However, in many cases business objects are not simple, instead they have very deep relationships with other objects. So if you need to send these objects in disconnected mode then you have to realize these objects along with dependent objects. This is just additional overhead and cause data-coupling. I like to design services using top down design and based on explicit contract. I want the interface and all objects that it is using or returning explicit. So, I actually prefer DTOs in these cases, because I know exactly what data the service needs and don’t introduce unnecessary data coupling.