Six years later, this needs a major update.
The simple answer is yes. But the complex answer is no.
No, SOA doesn't require Anemia. But at the same time, an enterprise system isn't required to be written using SOA. And similarly, architecture isn't a requirement at all for any code. It would be a nightmare, but you could package every bit of functionality into one module if you wanted.
Simply put: OO was originally defined by how it was different from its predecessors. More specifically: C++ was defined by how it was different from C. But the definition of OO has changed. We now have a multitude of OO Principles.
Disclaimer: Many of these principles were partially or wholly created prior to OO, and were simply claimed or updated during the OO revolution. Also, I realize OO has been around for LONG-Before C++, but that doesn't change my statement:
Encapsulation, Inheritence, Polymorphism, Separation of Concerns, Persistence Ignorance, High Cohesion/Low Coupling, S, O, L, I, D, and many more.
Not only that, but if you follow DDD and/or TDD while following these principles, you almost don't have to architect at all. Just by following these principles, you naturally end up with a Service-Oriented Architecture that uses Anemic Domain Models.
Think about it. If you have an Employee class with Save(), SendMessage(), and PayEmployee()... you are breaking so many rules of the current OO Principles.
When you analyze and pull out certain responsibilities into different services, repositories, commands, factories, etc... You Can't Help but have an Empty Employee Class... sort of.
Sort of?
In honesty, you need to keep the idea of Value Objects in mind. Not only has the definition of OO evolved, but the definition of "Anemic" has evolved also. The Employee class should certainly not be empty. It can have plenty of "Business Logic" in it.
The Employee class can have:
- A parameterized constructor, where the parameters are validated
- Readonly Properties that calculate fields
- Employee.ToString(), Employee.TryParse(), and similar object methods
- Possibly others, specific to the Employee
In essence, the Employee is still anemic. There will certainly never be any algorithms or code-flow logic in a domain model. But there isn't just one kind of Business Logic.
When Martin Fowler said Anemic Domain Models were an Anti-Pattern over a decade ago, it was already becoming more and more viable. His reasoning was twofold, and both folds are old news.
His first fold first was that his defending definition of OO was that the Code and Data were married, or "combine data and process together", opposed to old procedural style. This is only true in bad code, unfortunately. If we follow Inheritence and Polymorphism, we know that functions don't REALLY live in the class. They live at pointers so that inherting classes can override and move them around. But... do they live in the code to increase readability? They certainly shouldn't! They should be defined in Interfaces and Abstractions, and only implemented in the classes. Sorry Martin, but while you were right that the Code/Data marriage was a huge original selling point for OO 2 decades ago, it isn't so much the matter-at-hand now.
His second fold was that he disqualifies SOA as being done incorrectly, and points to some descriptions that closely resemble what we call N-Tiered Architecture today. Granted, I realize this isn't new technology, but definitions have changed over the years.
Not only Martin Fowler, but many others after him had immediately cited his article and therefore said SOA was, itself, an Anti-Pattern because it required Anemic Models, which Fowler says is an Anti-Pattern.
So we're down to this...
Anemic Domain Models aren't really as Anemic as people believe. And SOA is required, we can't discount it. Unfortunately, this is just simply the way things are.
Why is SOA required? - This is getting too descriptive. But long-story-short: In the 90's domain software ran on PC's and Servers... and hardware "Plugged-Into" those monoliths. These days we have literally trillions of "computers" all around us. Smoke-Detectors, Refrigerators, Watches, Phones... These days The Computers Plug Into The Things. So every idea, department, CONCERN, and object is its own small domain. We require SOA to write them up into their own little services, and even sub-services.
Therefore: Applications now plug into Services (Instead of Services plugging into Applications). To create SOA, we simply follow the current rules of OO, such as SOLID and Separation of Concerns. And when we do so, we naturally arrive at Anemic Domain Models... sorta.
So no, Anemic Domain Models aren't required for SOA. They are a natural result of following current principles and standards.
