Objektreferenz vs Referenz durch Id in DDD Aggregate

Question

Im Pluralsight-Kurs Domain-Driven Design Fundamentals gibt es ein Beispiel, wie der Entwurf eines Aggregates Gestalt annimmt. Das Beispiel beinhaltet Patienten Termine in einer Klinik. Der Termin hat Beziehungen z.B. zu einem Arzt oder einem Prüfungsraum. Und dem Beispiel geht eine Analyse voraus, die zu dem Schluss kommt, dass Appointment nicht eine aggregierte Wurzel für Doctor and ExamRoom sein sollte. Und ein Schritt in der Designentwicklung geht von dem Termin, der Objektreferenzen auf Doctor- und ExamRoom-Objekte hat, hin zu primitiven IDs dieser anderen Entitäten, DoctorId und ExamRoomId. Sie motivieren, diese Änderung mit den Worten: „Durch einfache die IDs der Konzepte im Zusammenhang mit eher als Objektreferenzen wir, um sicherzustellen, sind in der Lage, dass das Erstellen und Ändern Termin einen minimalen Einfluss auf unserem System hat, wenn wir unseren Termin bestehen bleiben“

Meine erste Frage: Ist das ein allgemeines Entwurfsmuster? Wenn ich es richtig verstehe, würde es zu etwas verallgemeinern: Wenn Objekt A sich auf Objekt B bezieht, aber das Arbeiten mit A niemals Änderungen an B nach sich ziehen sollte, dann referenziere es mit seiner ID, nicht mit B selbst. Ist das etwas, was du empfehlen würdest?

Meine zweite Frage: Hat das etwas mit DDD zu tun? Ich meine die Tatsache, dass Termin nicht eine Gesamtwurzel des Arztes sein sollte, bedeutet nicht, dass es Objektreferenzen nicht halten kann, oder fehle ich etwas?

Answer 1

1. Ich denke, das ist ein gemeinsames Design-Muster, zumindest im DDD-Universum. Evans sagt in DDD:

Die Wurzel ist das einzige Mitglied des Aggregates, dass außerhalb Objekte erlaubt sind Verweise auf zu halten, um

Wenn Sie einige ORM wie Hibernate verwenden, werden Sie vielleicht haben Lazy Loading, um tief verwurzelte Objektstrukturen mit Objektverweisen zu bewältigen. Einige Leute betrachten faules Laden ein Anti-Muster.

Werfen Sie einen Blick auf this QA, um das Konzept der Aggregate besser zu verstehen. Persönlich bin ich davon überzeugt, dass klar definierte Aggregatgrenzen Ihre Architektur verbessern.

2. Wenn Sie Aggregatgrenzen implementieren, hat Ihr Termintyp höchstwahrscheinlich keine direkten Objektverweise auf einen Arzt.

UPDATE: Vaughn Vernon spricht über rules that spell out the current consensus view of DDD leaders on the style of aggregates (Teil II):

[DDD] gibt an, dass ein Aggregat Verweise auf die Wurzel der andere Aggregate halten kann. Es ist jedoch zu beachten, dass dies nicht das referenzierte Aggregat innerhalb der Konsistenzgrenze des eines referenzierenden Aggregats platziert. Die Referenz verursacht nicht die Bildung von nur einem ganzen Aggregat.

Er fährt fort:

Wenn Sie mehrere Instanzen in einer einzigen Transaktion zu verändern, sie kann ein starker Hinweis darauf sein, dass Ihre Konsistenz Grenzen falsch sind. Wenn ja, ist es möglicherweise eine verpasste Modellierungsmöglichkeit; ein Konzept Ihrer ubiquitären Sprache wurde noch nicht entdeckt, obwohl es winkt seine Hände und schrie Sie an (siehe Teil I).

In meinem Verständnis sollte der Termin direkte Objektreferenzen zu anderen Aggregatwurzeln wie dem Doktor nicht halten.