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 guess your architecture is SOA based and implemented using messaging, then the domain model should lay inside your the service layer. That means it is not necessary to force the entire architecture to be formed into domain model but you can apply that in the sub-architecture.

Answer 3

I've found that most programmers just don't grok OOP. When it was introduced everyone rejoiced about how we'd no longer program yet another address data structure and how these Classes would marry code to data so that we wouldn't have to write more validation code.

Then, reality set in: My idea of an address doesn't always jive with someone else's. Worse, my concept of an address may change depending on the system I happen to be working on today. And that's a simple one.

And, it got even worse. Inheritance? What's that? Abstract, virtual, .. just keywords to put in the code to shut the compiler up.

And worse: code patterns. Need to validate an object? just use this helper pattern over here...

So we arrive at the point where most people believe a "class" is either a struct or a dumping ground for random functions that might be related in some way but god forbid you put the actual code for the class with the data defined by it.

Answer 4

This is exactly what I could not understand about people getting so excited about web services. Don't get me wrong, some good ideas there, but I see no difference to procedural programming here. Look at your architecture. What you describe is just using all the OOP stuff to make it perfectly procedural. How easier would it be to use plain data structures, algorithms and modules? I do not know your situation, but consider how easier it might be using relational database with stored procedures and some bindings to web services. One other answer seems to agree with me in a sort of a way... I would like to hear what you think, if it would make more sense in your situation and if not why? Am I mistaken about the procedural nature of web services?

Answer 5

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

Answer 6

Here are some resources that explain it better.

SOA Design Pattern

Achieving Integrity in a SOAD

Why your SOA should be like a VW Beetle