Martin Fowler betrachtet Anemic Domain Model als ein Anti-Pattern.Rich Domain Model und ORM
Auch das Rollen des Persistenzmodells als Domänenmodell scheint aufgrund von Object Relational Impedence Missmatch schwerwiegend zu sein. Für Beharrlichkeit und Normalisierung sakes neigen wir dazu, Klassen in sehr kleine kleine Stücke zu zerlegen, Slapping-Methoden auf diese Klassen ist albern. Plus-Persistenz ändert sich selten, aber Geschäftslogik ändert sich ein gutes Stück.
Also brauchen wir ein DomainModel, das auf dem Persistenzmodell aufbaut (anstatt ein und dasselbe zu sein). Dieses Domänenmodell enthält dann Geschäftslogikeigenschaften und -methoden.
Aber jetzt sind diese Domain-Modelle immer noch hinter dem Service, und um sie nach außen offen zu legen, müssen wir sie zu DTOs konvertieren.
Wir machen so mannigmappings hier.
- Persistenz zu Domain Model
- Um Domain Model in DTOs konvertiert entlang zwischen den Diensten passieren
Es endet hier nicht, da der DTO muß in das Ansichtsmodell abgebildet werden.
All dies und das Problem der Duplizierung der Validierungslogik geht immer noch nicht weg, weil der Client eine Echtzeitvalidierung wünscht. ViewModel weiß nichts über die Validierung. In einem SPA müssen Sie beispielsweise die Validierungslogik auf der Clientseite (normalerweise in JavaScript) erneut schreiben.
Auch Dienste sind von Natur aus zustandslos (Nachricht oder RPC-orientiert), also machen wir all diese Kartierung, zwischen Persistence, zu OO dann zurück zu Procedural, zu welchem Nutzen? Wie würden Sie die Kosten für die meisten IT-Budgets praktisch rechtfertigen?
Ich bekomme, wie vollständige DDD, mit Aggregatwurzeln, Domain-Modelle usw. wäre "cool" aber wie können Sie die Kosten und die Auswirkungen auf dev Produktivität rechtfertigen?
Antipattern (oder Antipattern) ist ein Muster, in geschäftlichen oder privaten verwendet Operationen oder Software-Engineering, die häufig verwendet werden, jedoch ist unwirksam und/oder kontraproduktiv in der Praxis
Und wenn ja , würden DDD und Rich Domain Model nicht in die Anti-Pattern-Definition über dem "Lean" Domain Model passen. Entschuldigung, ich verachte das geladene Wort "Anemic".
Indem Sie das Domänenmodell "Lean" beibehalten, erlauben Sie es tatsächlich, ohne das "abstrakte Abhängigkeitsprinzip", "sich nicht selbst zu wiederholen" und den zeitraubenden, langwierigen und fehleranfälligen Prozess der Zuordnung einer Daten zu teilen Träger zu einem anderen, und was auch immer verbundenen Unit Test, der darüber hinaus geht (es sei denn, Sie denken, Mapping ohne Unit Testing zu tun und hoffen auf das Beste).
Ich denke, der Artikel, den Sie verlinkt haben, fasst das Dilemma zusammen. Abgesehen davon, dass ich nicht daran glaube, Domain Model durch die Leitung zu schicken, scheint das die Aufgabe eines DTO zu sein. Es macht keinen Sinn, Verhalten auf dem DTO zu haben und dies dem Kunden offen zu legen. Für mich ist die Architektur also nur "machbar" mit einer weiteren Ebene der Abstraktion und Kartierung zusätzlich zu den 3, die er erwähnt hat. Und das ist eine Menge Mapping! Zu sagen, dass die andere Möglichkeit der Einführung von UI-Bedenken in die Domäne aus Gründen der Wiederverwendung nicht richtig ist, ist auch richtig. Ich denke, es gibt ein "glücklicheres" Medium zwischen den beiden extremen Pollern. – Alwyn
"Bewegen Sie weniger Daten herum und die Dinge werden wahrscheinlich einfacher" - Seine eigene Schlussfolgerung am Ende des Artikels, die für mich wie Lean Model klingt. – Alwyn
"Es macht keinen Sinn, Verhalten auf dem DTO zu haben und dies dem Client offen zu legen." Jetzt verstehe ich die Verbindung, die Sie zwischen Rich/Anemic Domain Model und Layering herstellen. Implizieren Sie, dass Domänenobjekte von so viel Geschäftslogik wie möglich entfernt werden sollten, um sie direkt an die UI-Ebene zu senden, ohne DTOs zu benötigen? Oder ist es etwas anderes, das du als "Lean Model" bezeichnest? – guillaume31