[Alg/Spring 2.0] Anemic Domain Model

[-FoX-]

Wat is een 'Anemic Domain Model'?
Volgens Martin Fowler
Als je domain objecten geen domain logica bevatten en dus eigenlijk niets meer zijn dan simpele objecten met hun properties, dan wordt dit een anemic domain model genoemd. Een anti-pattern.

Wat is er verkeerd aan een 'Anemic Domain Model'?
Wat ik me dus afvraag is wat hier nu precies verkeerd aan is? Dit naar aanleiding van de aankomende release van v2.0 van het Spring framework en volgend artikel Spring 2.0 vs. the Anemic Domain Model.

Op het eerste zicht kan ik niet direct zien wat hier nu het voordeel aan is, enkel maar meer werk om het in elkaar te zetten, meer configuratie en minder overzicht. Verder komen er nog een aantal verplichten bij kijken door de code te compileren met de aspectJ compiler en je domain objecten te voorzien van annotaties (ok, hier zou ik nog wel mee kunnen leven).

Het enige wat er eigenlijk gedaan wordt is de verantwoordelijkheid meer naar de objecten toeschuiven om zichzelf te delegeren naar de persistence layer. Maar waarom is dit nu nodig? Daar dient mijn service layer toch voor?

M.a.w. ik zie de échte nadelen van een anemic domain model niet in. Ik zou graag willen weten hoe jullie hierover denken. Maken we het op deze manier niet te complex?

[Verwijderd]

Het gaat er volgens mij als ware om dat je een heel duidelijk business model kunt neerzetten. Want in het ideale geval moet je je business als geheel uit je applicatie kunnen trekken en dit over hevelen naar een andere omgeving. Dus dat betreft niet het eigelijke saven en updaten zelf, maar wel het invoken daarvan.

De businesslogica behoort dus toe aan de domein objecten. Ik zelf vind het idee mooi, maar de implementatie niet. Bijvoorbeeld omdat je voor je presentatie laag een adapter nodig hebt die als ware er weer ouderwetse domein objecten van maakt.