Ez a második linked egyáltalán nem arról, hogy anemic domain model + service layer, csak nem ismeri fel.
Ott, amikor elkezdi a User classt normális domain objektummá tenni, akkor azt a specifikációs követelményt önti kód formába, hogy "képesnek kell lenni egy-egy felhasználó számára (amely felhasználó egy név és e-mail cím párost jelent) üzenetet küldeni".
És igen: az üzenetet a felhasználónak küldjük, épp ezért a User API-jának a része az, hogy üzenetet kap. Az, hogy HOGYAN kap üzenetet (azaz miként valósul meg a MessageService) az megint más kérdés.
Épp ezért a User mint magasszintű absztrakciójú class definiálja, hogy neki szüksége van egy MessageService-re, hogy üzenetet lehessen neki küldeni, és a MessageService-nek ez és ez az API-ja. Aztán ezt a magasszintű API-t majd más alacsonyabbszintű megvalósítások implementálják, ez egy példa a dependency inversionre.
Amúgy a Step 1-ben van leírva (csak nem felismerve) a probléma:
"This may be as a result of an explicit design decision or, more probably, it comes from the fact that certain pieces of logic just cannot be implemented in the domain entity because it is a persistent class and has no internal references to external services"
Ez egy rossz megközelítés. A domain objektumot köti annak I/O-jához: a persistent class nem maga a domain objektum. Csak egy eszköz arra, hogy az objektumunk állapotát valamilyen I/O rétegen keresztül elmentsük, hogy később az állapotot visszatölthessük.
Aki a persistent entityket domain entitynek tekinti, az rossz megközelítés. A persistent entity class csak egy I/O réteg, nem maga a domain model.