Anémický model se často projevuje následovně, doménový model je tvořen objekty, které se jeví na první pohled jako běžné business entity. Tyto entity však jsou pouhé přepravky na data (DTO) a obsahují zpravidla jen constructor, gettery a settery. Samotný doménový model takové aplikace tedy obsahuje žádnou nebo velmi málo logiky (zajistí si datovou integritu, zvaliduje se).
Problém tohoto přístupu nastává, když tyto nenápadné DTOčka vedou k příliš těžkopádné a tlusté aplikační vrstvě. Tedy existuje plno rozsáhlých servis, které obsahují veškerou logiku domény (provádějí výpočty a aktualizují entity). Tyto servisy ještě navíc doprovází spousta manažerů a DAO a celé to vede k těžce udržovatelným a refaktorovatelným celkům.
Anémický model je často programátory objektově orientovaného paradigmatu považován za anti-patern. Řešením tohoto stavu má být podle nich větší využití objektově orientovaného přístupu v návrhu aplikace. V OOP se kombinují data a metody v jeden celek. Interakce mezi servisami a DAO může být také procedurální nebo funkcionální a místo objektů, si vystačíte se strukturami, recordy nebo datovými typy. Anemický model může být mezifáze vývojáře, který opouští OOP.
Ačkoliv už název zní poněkud nezdravě, má Anémický model i benefity
- jasně odděluje mezi logiku a data
- v menších aplikacích funguje dobře
- s bezstavovými entitami se snadněji a bezpečněji pracuje
Částečné řešení je tedy přesinout logiku ze servisní vrstvy do doménových tříd. Na druhou stranu, pokud by byla veškerá logika řešena v entitách, stávaly by z nich snadno „God objekty“. Takové entity by měly spoustu zodpovědností a hlavně by musely vědět o vrstvách a částech aplikace, o kterých je zbytečné, aby vůbec věděly. Zkrátka měl bys nezdravě vysokou míru provázanosti systému.