I See AnemicDomainModels

AnemicDomainModel is an anti-pattern I seem to keep coming across. It's when a system has objects which represent its business entities, but all the business logic is crammed into static classes. The static classes (usually called SomethingOperations, or SomethingServices) take business entity instances in their methods and manipulate those entities directly, implementing business logic in a procedural fashion.

The problems with this setup:

  1. Your 'business objects' are just glorified data carriers - bags of getters and setters with no behaviour. This makes it much more difficult to use all those neat OO tricks which can simplify the way a system does its work, like polymorphism. Your static classes get filled with switch statements and logic paths based on whether the object they're dealing with represents Thing1 or Thing2 or Thing3, instead of the behaviour being implemented by Thing1, Thing2 and Thing3, with another class just invoking that behaviour. Your system becomes more complicated than it needs to be, and everyone gets very sad.
  2. Because your business logic classes are static, the classes that help them carry out their work also have to be static. You end up with a network of static classes strongly coupled to other static classes by direct references, with no visibility of the dependencies. This makes it much more difficult to write automated tests, which makes your system fragile and difficult to change. Everyone gets very sad.

OO has been around for decades – with the Gang of Four patterns book published nearly 20 years ago – so why are people still writing these sorts of systems? I think it betrays a fundamental failure to grasp the nature of OO. OO systems are composed of objects which are composed of other objects, with behaviour arising through object-object interactions. I see AnemicDomainModel systems built by people who first learned procedural programming and later tried to incorporate OO into their repertoire, but didn't manage to make the necessary shift in their thinking. They tend to have decades of experience, and to therefore be responsible for creating systems. They tend to be members of the large majority of developers who don't continue to read about or study their craft, and therefore miss out on better ways of doing things. As the systems get bigger and creak under their design flaws, they blame the business coming up with requirements late, changing their minds, or coming up with things they never expected – all things a well-designed OO system can handle.

How do you get from an AnemicDomainModel to a more best-practice OO system? Ideally you start by levering in some testability seams so you can get test coverage without having to call web services or query databases – this will protect you as you refactor. You can then pick out bits and pieces to move from static classes into appropriate business objects – perhaps starting by replacing those switch statements with polymorphism. It's a long road - and naturally the business will be pushing for new functionality to be added the entire time - and it boils down to a lack of education, or desire to educate oneself. Good luck!

Print | posted @ Saturday, November 30, 2013 9:21 PM

Comments on this entry:

Gravatar # re: I See AnemicDomainModels
by Simon at 12/2/2013 1:47 PM

I've yet to find a company/dev team (in and around London) that is interested in anything along the lines of DDD and BDD. A lot of the devs know all the buzz words but it's like they've skim read the relevant books and blogs purely to pass interviews.

The current company I'm contracted at (large hedge fund) has folders in the solution for Entities, Value Objects, Repositories, etc (read any more than the headings in the book and you'll realise that grouping should be by feature). All you'll find is auto-properties (c#) in any of the entities and static helper methods in the Value Objects. Aggregates are never mentioned. There are, however, lots and lots of *Manager and *Service classes :)

I've just found a real apathy towards anything that's not purely technical. Developers are just not interested in understanding the problem domain. They just want a peice of paper that has all the business requirements on so that they can just churn out lines of code (and complain at how bad the business requirements are).

I know I'm tarring everyone with the same brush, it's just very frustrating that this seems to be the norm.
Gravatar # re: I See AnemicDomainModels
by Steve Wilkes at 12/2/2013 6:17 PM

I feel your pain, Simon - that's more or less exactly my experience. It is a sad fact that most developers 'learn to code', then go on for years collecting their pay cheques and paying little or no attention to what's happening in the industry outside their office walls. I've been lucky enough to work with some really good programmers and architects, but they're a small minority. For whatever reason, it's the nature of our industry.
Gravatar # re: I See AnemicDomainModels
by Andy Miles at 12/2/2013 8:15 PM

Agreed again. And it's the same in the USA. Having coped with the challenge of "learning to program" (or stated correctly "learning the syntax, libraries, and maybe some of the idiomatic use of a language") most developers go straight to "how can we do this" mode and just start coding. Part of it is pressure to get it done quickly; but part of it is fear of "can I even do it". Good developers know you have to consider options and their trade offs before selecting a solution. Poor developers seem to regard thinking things through as analysis paralysis. And then all we get is unmaintainable, technology-coupled anemic models fed by transaction scripts.
Andy Miles: www.needpoweredchange.com
Gravatar # re: I See AnemicDomainModels
by Tom Parrish at 12/4/2013 12:00 PM

QConsultancy or contract based work does demonstrate more apathy towards writing good code. I've found that since I've worked for companies that offer software as a service, we evaluate our need for code alot more. Every bit of code is a liability, as it all needs to be maintained, so we try any code we do write as maintainable as possible, otherwise we end up wasting developer time when we need to enhance or change a subsystem, as the poor developer has to spend time trying to understand the software, rather than being able to dive straight in.
Gravatar # re: I See AnemicDomainModels
by Sam Shiles at 12/8/2013 10:28 AM

The service/manager plague that infests and continues to infect our code bases is the antithesis of good OO and DDD. Domain models as DTOs are the norm and I don't see that changing any time soon. I don't believe nhibernate helps with this situation much as it places too many constraints on the domain objects themselves and means you end up violating best practices just so your classes play better with nhibernate (think mutability, rich constructors that result in fulling instantiated objects).....oh and all those virtuals (for the love god!).

The one project I had the fortune of working with Steve on was the exceptional to the rule....you should see what they did to it after we left though!
Gravatar # re: I See AnemicDomainModels
by Steve at 12/8/2013 11:43 AM

Haha - awww, they didn't spoil it, did they Sam? To be fair, there's things I would have done differently on that project if we were starting it now, but isn't that almost always the case? Code is legacy code as soon as it's written and all that. Good to hear from you, hope all is well :)
Gravatar # re: I See AnemicDomainModels
by JD at 12/8/2013 4:04 PM

Get a room you two. JD
Post A Comment