Once an anti-pattern: Anemic Domain Model

TL;DR Many of the most commonly used patterns & "conceptual industry standards" in software development have their roots in Object-Oriented design. However, it's time to realize that...

Latest Post Mixing warsaw.ex by Sebastian Gebski

TL;DR Many of the most commonly used patterns & "conceptual industry standards" in software development have their roots in Object-Oriented design. However, it's time to realize that OO is not the only viable way this day, so in some cases yesterday's anti-patterns may be a preferred way to go today. Anemic Domain Model is a perfect example here - not only I wouldn't discourage using it anymore, in fact I find it well aligned with all the goodness "re-discovered" recently thanks to FP.

Life can be very ironic: occasionally yesterday's patterns appear to be today's anti-patterns & vice versa too. I've encountered such a situation recently - we were having a group conversation on modern conventions for building business logic & at some point one of my colleagues has openly questioned the proposed model (business logic within separate service functions, POXO model entities) with a following statement:

"Guys, don't you think that depriving the model of actual business logic (& putting it in separate, stateless services) makes it anaemic? Haven't you read Martin Fowler's article on Anemic Domain Model? It's an acknowledged & widely recognized anti-pattern!"

If you get into the details (of the article mentioned), the key reasoning is like that:

"The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together."

Martin Fowler, Anemic Domain Model, 2003

Doesn't it sound controversial today? Like perpendicular to the core principles of Functional Programming? Which is supposedly more testable, composable & less prone to excessive coupling? And is being zealously Object Oriented a thing anymore, even for typically OO languages like C# or Java?

Ok, I think you've got the idea.

More than 1 (good) way

Software development is evolving, so are its methods & even patterns. Classics are classics, but it doesn't mean one has to follow blindly what was written (/said) 5, 10 or 15 days ago. Even if it was such an authority as Martin Fowler (who has & will always have my eternal respect & gratitude for what he has done to the industry & how he has impacted my own career - by his public works, of course).

Does it mean that Martin Fowler was (or rather IS, in the reality of 2017) wrong about anemic Domain Model? Well, "it depends" :)

  1. You can still build your business logic in a traditional OO way (that feels the most intuitive for the human beings), with rich, conceptual models that aggregate both data & behavior within model's entities, but ...
  2. ... in fact we've all learned our lesson on FP (& its conceptual descendants). There's nothing wrong in using a modern variation of what we've formerly known as "transaction scripts" (it's a slight simplification, pardon that) to process (input -> output) bare POXOs (Plain Old X Objects)

"Anemic Domain Model" is just another viable option (one of few), that (for the practical reasons) may even be the most preferred one these days, as it's well aligned with typical architecture principles of 2017:

Pic: © 5second - Fotolia.com

Sebastian Gebski

Published a year ago

Comments?

Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.