Im Pluralsight-Kurs Domain-Driven Design Fundamentals gibt es ein Beispiel für das Design eines Aggregats nimmt Form an. 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 der Termin keine Zusammenfassung von Doctor und ExamRoom sein sollte. Und ein Schritt in der Designentwicklung geht von dem Termin, der Objektreferenzen auf Doctor- und ExamRoom-Objekte hat, zu dem Halten von primitiven IDs dieser anderen Entitäten, DoctorId und ExamRoomId. Sie motivieren diese Veränderung, indem sie sagen: "Indem wir einfach die IDs der zugehörigen Konzepte anstelle von Objektreferenzen einfügen, können wir sicherstellen, dass das Erstellen und Ändern von Terminen minimale Auswirkungen auf unser System hat, wenn wir unseren Termin"
beibehaltenMeine erste Frage: Ist das ein allgemeines Designmuster? Wenn ich es richtig verstehe, verallgemeinert es sich zu etwas wie: Wenn Objekt A sich auf Objekt B bezieht, aber das Arbeiten auf 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 keine Objektreferenzen darauf halten kann, oder fehle ich etwas?
Der Stamm ist das einzige Mitglied von AGGREGATE, das es externen Objekten erlaubt, Referenzen auf
zu halten
Wenn Sie ORM wie Hibernate verwenden, müssen Sie vielleicht mit dem Lazy Loading arbeiten, um tief verwurzelte Objektstrukturen zu bewältigen, die Objektreferenzen haben. Manche Leute halten ein Anti-Pattern für lazy loading.
Schauen Sie sich diese QA an, um das Konzept der Aggregate besser zu verstehen. Persönlich bin ich überzeugt, dass klar definierte Aggregatgrenzen Ihre Architektur verbessern.
UPDATE: Vaughn Vernon spricht über Regeln, die den aktuellen Konsens der DDD-Führer über den Stil von Aggregaten festschreiben (siehe Teil II):
[DDD] gibt an, dass ein Aggregat Verweise auf den Stamm von enthält andere Aggregate. Wir dürfen jedoch nicht vergessen, dass dies nicht der Fall ist Platzieren Sie das referenzierte Aggregat innerhalb der Konsistenzgrenze von man referenziert es. Die Referenz bewirkt nicht die Bildung von gerade ein, ganzes Aggregat.
Er fährt fort:
Wenn Sie mehrere Instanzen in einer einzigen Transaktion ändern, wird dies ausgeführt kann ein starker Hinweis darauf sein, dass Ihre Konsistenzgrenzen falsch sind. Wenn ja, ist es möglicherweise eine verpasste Modellierungsmöglichkeit; ein Konzept von Ihrem ubiquitäre Sprache wurde noch nicht entdeckt, obwohl sie winkt seine Hände und schreien Sie an (siehe Teil I).
Nach meinem Verständnis sollte der Termin keine direkten Objektverweise auf andere Aggregatwurzeln wie den Doktor enthalten.
Tags und Links domain-driven-design