DDD - Anti-pattern

In the context of Domain-Driven Design separating business logic from the Domain Model is an anti-pattern, which is usually described by the term Anemic Domain Model (Evans, 2003; Fowler, 2003).

According to Fowler (2003), anemia appears when objects of a model provide only methods with the only responsibility of setting or getting their private attributes, while the logic that manipulates the model's state resides on a separate layer containing only stateless service objects. This anti-pattern is promoted by many enterprise application frameworks (e.g. JEE) and although this makes it easy to add new behaviour to an existing (anemic) domain model, it is harder to process new data structures in existing service objects (Fowler, 2003; Nillson, 2006; Martin, 2009).

References

• Evans, E. (2003) Domain-Driven Design: Tacking Complexity In the Heart of Software. Boston: Addison-Wesley.
• Fowler, M. (2003) Anemic Domain Model. [Online] Available at: http://www.martinfowler.com/bliki/AnemicDomainModel.html [Accessed 26th May 2013].
• Martin, R. (2009) Clean Code: A Handbook of Agile Software Craftsmanship. Boston: Prentice Hall.
• Nilsson, J. (2006) Applying Domain-Driven Design and Patterns. Boston: Addison-Wesley.

This post is an excerpt of my MSc Thesis titled "Applying Domain-Driven Design in Python - designing a self-hosted Read-it-Later service" (January 2014).