Reiches Domänenmodell vs anämisches Domänenmodell [geschlossen]

Was ist eine bessere Praxis in der Web-Entwicklung, ein anämisches Domänenmodell oder ein reiches Domänenmodell?

Anemistisches Domänenmodell bedeutet, dass Entitäten dumme POJOs sind, die einem persistenten Speicher zugeordnet sind. Getters und Setter validieren den Statusübergang nicht, vertrauen jedoch der darüber liegenden Ebene. Es liegt in der Verantwortung des Service-Layers, den rechtlichen Status der Entität zu überprüfen und einen Fehler auszulösen, wenn die Geschäftsregeln verletzt werden. So kann ich mit Spring und Hibernate Webanwendungen erstellen.

Ein Rich-Domain-Modell bedeutet, dass sich die Validierungslogik (Geschäftsregeln) in den Entitäten selbst befindet, z. B. wenn eine Ausnahme von einem Setter ausgelöst wird, wenn ein unzulässiger Statusübergang versucht wird.

Nachdem wir einen tieferen Einblick gewonnen haben, ist das Rich-Domain-Modell näher an den OOP-Prinzipien, wo ein anämisches Domain-Modell genauso prozedural ist wie die Übergabe einer Struktur an die C-Funktion (in der Tat sind Setter und Getters hier nur ein Standard) Javabean Vertrag). Warum wird dann das Modell der anämischen Domäne mehr angenommen? Was sind die Vor- und Nachteile beider Ansätze?

Ich konnte einige Probleme mit einem Rich-Domain-Modell feststellen. Wenn beispielsweise der gültige Zustand einer Entität vom Zustand einiger anderer Entitäten abhängt, die Entität jedoch nicht die Referenz auf alle Entitäten hat, wie können wir den Status innerhalb der Entität validieren? Wir könnten von Setter auf die Datenbank zugreifen, aber dies würde den Persistenzmechanismus zur Geschäftslogik verleiten, in der Tat ein sehr schlechter Entwurf. Außerdem würde eine unnötige Validierung durchgeführt, wenn ORM ein bereits validiertes Objekt aus einer Datenbank lädt und seine Werte einstellt! Mit der Business-Logik, die sich in der Service-Schicht befindet, ist es viel einfacher, eine Ad-hoc-Validierungslogik hinzuzufügen, wenn sich die Anforderungen ändern, und das Domänenmodell von Infrastruktur-Code sauber zu halten. Tatsächlich ist in beiden Fällen die Geschäftslogik mit der Persistenz verknüpft, und in der Praxis sind Domänenmodelle ohne die Logik wertlos, aber wenn die Logik in Diensten liegt, könnten wir verschiedene Regeln auf dieselben Entitäten anwenden anderer Kontext. Habe ich Recht, dass dies der Zweck der Service-Schicht ist?

Außerdem erwartet der Ruhezustand oder ein anderer Persistenzmechanismus, dass Entitäten POJOs sind und nur daran interessiert sind, die Werte zu erhalten und festzulegen. Natürlich, mit Rich-Domain-Modell-Datenbank sollte immer in einem konsistenten Zustand sein, aber was würde passieren, wenn es nicht wäre? Welches Impact-Rich-Domain-Modell hätte moderne ORM-Frameworks?

Ich habe diese Frage gestellt, als ich kürzlich gelesen habe, dass das anämische Domänenmodell ein Anti-Muster ist. Ich bin verwirrt und möchte einige für eine solche Aussage rechtfertigen.