Announcer: Now, it’s time for OO’s resident San Diegan, the man who stands between procedural spaghetti and your codebase, El Moffdo!
It’s Saturday, and you know what that means:
Announcer: From the EIP Sylvanian Operations Center, somewhere in south-eastern PA, it’s Nowhere To Run!
That’s right, ladies and gentlemen, we’re back for 09 with a shorty but a goodie:
Based on 100% fact. This diagram hangs in my cube.
| << Previous | Next >> |
 |
Announcer: You’re reading the EIP web-ring. |
Anemic Domain Models have their vices, to be sure, but there is an argument to be made for their use, and it is a compelling one: re-use.
By separating data structure from behavior, the data structure can be re-used across multiple applications which have different behavior for entities. Of course, this is a big trade-off: readability, maintainability, and encapsulation for reusability. Nothing is ever for free in this line of work.
The problem is that this is quintessentially anti-OO, and anti-domain-driven design. If you are ever to make the move to DDD in a company with a stated goal for object re-use, like mine, then this issue has to be addressed.
This is part 2 of the series on Anti-Corruption Layers. If you missed part 1, go take a gander at it.
First, as I predicted, the Big Harry Design Up-Front was not the design that ended up being implemented. Fortunately, there were only minor changes, which are in red:
Code Agitator, elected to be the villain, certified a menace
