DDD/Aggregat Wurzel/Mitgliedseinheit, die auf root-entity zeigt

Question

Ist es in Ordnung, wenn eine Mitgliedseinheit eines Aggregats root auf die Root-Entity zeigt (nicht umgekehrt)?

Angenommen, ich habe Population AR (wobei die Population die Root-Entität ist und PopulationMembership eine der Member-Entitäten ist).

Ich evaluiere die Richtung der Verbindung zwischen Bevölkerung und BevölkerungMitgliedschaft. Es gibt eine andere Entität am anderen Ende, Person (ein eigenes AR und PopulationMembership hat einen Verweis auf Person).

In der Welt der ER (Datenbank) würden wir normalerweise eine Assoziation herstellen, die von PopulationMembership auf Population zeigt (population_membership ist die Verbindungstabelle in der Viele-zu-Viele-Beziehung zwischen Population und Person).

Aber ich denke, in der DDD-Welt sollte ich diese Gewohnheit brechen und die Assoziation dazu bringen, von Population (im konzeptionellen Modell) auf PopulationMembership zu verweisen.

Wie auch immer, ich würde gerne bestätigen, wenn wir (in einer anderen Situation vielleicht) eine Assoziation von der Mitgliedsorganisation zur root-Entität haben dürfen.

Irgendwelche Gedanken?

Answer 1

Ok, lassen Sie uns diese Frage in zwei Teile geteilt:

1. Ist es ok für Mitgliedseinrichtung Bezug auf seine Gesamt Wurzel zu halten?
2. Allgemeine Aggregat Modellierungsregeln

der von 1 Lassen Sie beginnen:

Nein, sollte in der Regel untergeordnete Entitäten nicht Bezug auf die Gesamt Wurzeln halten. Aggregatwurzel ist der Einstiegspunkt für das gesamte Aggregat und muss seine Konsistenzgrenzen beibehalten. Das bedeutet, dass jede Änderung am Aggregat über die Root-Entity (in oop durch Aufruf von Methoden der Root-Entity) weitergeleitet werden muss. Aggregierter Stamm kann Verweise auf untergeordnete Entitäten zurückgeben, sie müssen jedoch vorübergehend sein. Außerdem sollte der Client keine Änderungen an untergeordneten Entitäten außerhalb des aggregierten Stammverzeichnisses vornehmen - andernfalls kann die Konsistenz verletzt werden. Wenn ich das im Hinterkopf habe, sehe ich keinen Grund, warum untergeordnete Entitäten Verweise auf ihre Wurzel haben (aus der Sicht des Kunden - Sie haben bereits Zugriff auf die Wurzel, nicht wahr?). Die einzige Ausnahme, die ich gerade sehe, ist, wenn Sie das Modell auf bestimmte Bedürfnisse umstellen müssen (z. B. erfordert der Präsentations-Layer eine root-Entity-ID, um eine sinnvolle JSON-Ausgabe zu erzeugen). Aber selbst in diesem Fall würden Sie wahrscheinlich ein separates Lesemodell erstellen oder spezialisierte Assembler bereitstellen, um erforderliche DTOs zu erstellen.

Ok, nun zum zweiten Punkt:

Es scheint, dass Sie versuchen, Ihre Domain-Einheiten auf die gleiche Weise modellieren Sie Ihr Datenbankmodell bauen würden. Bei DDD sollten wir uns zuerst auf die Geschäftsanforderungen und das Verhalten unseres Modells konzentrieren. Datenbeziehungen sind beim Erstellen eines aussagekräftigen Domänenmodells nicht so wichtig (wir verfeinern das etwas später). Zunächst sollten Sie sich darauf konzentrieren, Business Case-Szenarien von Ihren Domain-Experten zu sammeln. Aggregate sollten auf echten Geschäftsinvarianten basieren. Sie sollten ein gemeinsames Modell zusammen mit Ihrem Team (einschließlich Geschäftsmitgliedern) erstellen. Es ist sehr wahrscheinlich, dass Ihr Design nach mehreren Wissensverknüpfungssitzungen völlig anders aussehen wird. Vielleicht ist Person nicht wirklich eine aggregierte Wurzel, sondern einfach ein Wertobjekt? Vielleicht brauchen Sie nicht einmal die Entität PopulationMembership? Der am häufigsten verwendete Entwurf für Aggregate ist nur eine einzelne (Root-) Entität mit mehreren Wertobjekten.Abgesehen davon - ich erstelle oft ein völlig separates Datenbankmodell, fast ohne Verbindung (außer id) zum Domänenmodell. Ich benutze eine Übersetzungsschicht (Mapper-Komponenten), um zwischen Domäne < -> dbmodel zu konvertieren. In meinem letzten Projekt unterschied sich mein db-Modell extrem von der Domänebene (es wurde speziell an die Anforderungen der Persistenzschicht angepasst - so wurden zum Beispiel viele flache Eigenschaften verwendet - nicht vollständige Objekte, sondern einfache Grundwerte). Im Falle einer relationalen db könnten Sie sogar explizit eine bidirektionale Relation angeben (in der Tat, Sie müssen nicht einmal ein orm verwenden). Es gibt viele Vorteile, wenn Sie Ihr DB-Modell vom Domänenmodell trennen. Das Design ist definitiv geschmeidiger. Die Mapping-Kosten (Entwicklerarbeit) zwischen db < -> Domain-Layer können jedoch für einfache Projekte zu groß sein. In diesem Fall beginne ich normalerweise mit einem gemeinsamen Modell und transformiere dann zu trennbaren Schichten.

Oh, eine andere wichtige Sache - es ist im Allgemeinen eine gute Idee, auf andere Aggregatwurzeln nur durch ID zu verweisen. Auf diese Weise haben Sie kein Problem mit komplexen Objektgraphen, und Sie müssen sich nicht darum kümmern, andere Aggregate innerhalb einer einzigen Transaktion zu modifizieren (der Aggregatstamm sollte keine anderen Stammbäume modifizieren). Wenn Sie zwischen Aggregaten kommunizieren müssen, verwenden Sie stattdessen Ereignisse.

Bitte finden Sie in der großen Artikelserie von Vaughn Vernon:

http://dddcommunity.org/library/vernon_2011/

Ich denke, diese Artikel, die Sie die aggregierten Modellierung helfen können Konzepte zu verstehen.