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" :)
- 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 ...
- ... 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:
- apart from systems based on actor model (still a rarity), stateless services are the reigning king - in 99% of cases processing is just about reading data from persistent storage, performing atomic operation that transforms state A into state B, writing down the result & discarding anything that was instantiated to serve the request (because f$%ck session affinity)
- "rich" domain model encourages & frequently leads to excessive usage of what is currently known as State anti-pattern (which ironically, is closely related to one of original GoF patterns) & in consequence: undue complexity. If you're interested in more details, you can check one of my past articles here
- in the age of Continuous Delivery worship, testability is crucial & this is where functional approach shines: the closer you get to function purity, the easier it gets to properly test your business logic; not without a reason some FP languages don't even have a single mocking library - it's just not needed anymore!
Pic: © 5second - Fotolia.com
