Today, many projects focus on Domain-Driven Design, but it is not always easy. One of the most important things are to separate the domain code from the code that only exists for technical reasons.
Mats Helander has written an InfoQ article about how to manage domain models with a concept he calls Domain Model Management. In the article, Mats leads the reader step by step though common problems regarding design and separation of concerns when trying to implement a domain model, explains ways to solve the problems and manages to teach aspect oriented-programming, a couple of design patterns and some things about object/relational mappers in the process.
In this excerpt from the article introduction, Mats reasons about where to put the infrastructure code:
As the amount of infrastructure code grows, finding a good architecture for dealing with it all becomes increasingly important. A big part of the question is - are we allowed to put some infrastructure code in our domain model classes or is that something which should be avoided at all cost?
The argument for avoiding infrastructure code in the domain model classes is strong: The domain model is supposed to represent the core business concepts that our application is dealing with. Keeping these classes clean, lightweight and maintainable is an excellent architectural goal for an application that intends to make heavy use of its domain model.
On the other hand, as we will go on to see, taking the extremist route of keeping our domain model classes completely free of infrastructure code - often referred to as using a Plain Old Java/CLR Objects (POJO/POCO) domain model - can also prove problematic. It will often result in clunky, less efficient workarounds - and some features just won’t be possible to implement at all that way.
This seems to indicate, as is so often the case, that we have a trade-off situation on our hands where we should try to put only just as much infrastructure code in our domain model classes as absolutely needed, but no more. We trade off some bloat in the domain model for some improved efficiency or enablement of some required Domain Model Management feature that wouldn’t work otherwise. Negotiating good trade-offs is, after all, a large part of what software architecture is all about.
Lean back and enjoy the full article about Aspects of Domain Model Management, and the accompanying source code.