Is Domain Anaemia appropriate in a Service Oriented Architecture?

Question

I want to be clear on this. When I say domain anaemia, I mean intentional domain anaemia, not accidental. In a world where most of our business logic is hidden away behind a bunch of services, is a full domain model really necessary?

This is the question I've had to ask myself recently since working on a project where the "domain" model is in reality a persistence model; none of the domain objects contain any methods and this is a very intentional decision.

Initially, I shuddered when I saw a library full of what are essentially type-safe data containers but after some thought it struck me that this particular system doesn't do much but basic CRUD operations, so maybe in this case this is a good choice. My problem I guess is that my experience so far has been very much focussed on a rich domain model so it threw me a little.

The remainder of the domain logic is hidden away in a group of helpers, facades and factories which live in a separate assembly.

I'm keen to hear what people's thoughts are on this. Obviously, the considerations for reuse of these classes are much simpler but is really that great a benefit?

Answer 1

I would agree a full domain model may not be necessary. However, I do think it's more painful to write tests for services with mocked data access objects than it is to write tests for non-anemic domain objects. I'm working on a project now where domain logic exists everywhere except in the domain model, scattered around in helpers and strategies and mediators, and the whole thing has become an unmanageable pile of legacy code even before it's gotten to production.

Thinking back to previous projects I do remember one that used anemic domain objects, it had a lot of issues, including a terrible homegrown xml database, but because it did take a service-based approach it was easy to take on the problems one at a time and make real headway. On the current project they tried to be clever and tie the domain objects to the database, ActiveRecord-style, and didn't make any efforts to control their dependencies. The tight coupling of domain objects to the database, overuse of static methods, and a spaghetti-like web of dependencies has been a big part of what has caused this codebase to become a prematurely brittle, inflexible, and untestable ball of mud. So I think while persistence-ignorant rich domain objects make testing of business logic much easier, the essential thing is to manage your dependencies.

Answer 2

I believe that an anemic domain while an OO anti pattern is in fact a SOA pattern. The rules have changed a bit as we have elevated our level of abstraction.

I am exploring further in a series i am writing, i also had a rant about it on my log last year. metallemon.blogspot.com/2008/07/soa-and-anemic-domains.html

http://hubpages.com/hub/Building-Service-Orientated-Architecture