DDD: Ist es richtig, dass ein Stammaggregat einen Verweis auf ein anderes Stammaggregat enthält?


16

Wenn Sie dem domänengesteuerten Entwurf (Domain-driven Design, DDD) folgen, ist es richtig, wenn ein Stammaggregat einen Verweis auf eine interne Entität enthält, die zufällig die Stammentität in einem separaten Aggregat ist?

Ich glaube, das ist nicht richtig, hauptsächlich wegen dieser Regel im Blue Book :

Nichts außerhalb der AGGREGATE-Grenze kann einen Verweis auf irgendetwas innerhalb enthalten, außer auf die Root-ENTITY. Die Stamm-ENTITÄT kann Verweise auf die internen ENTITÄTEN an andere Objekte übergeben, diese Objekte können sie jedoch nur vorübergehend verwenden, und sie können die Referenz möglicherweise nicht festhalten. Der Root kann eine Kopie eines VALUE OBJECT an ein anderes Objekt übergeben, und es spielt keine Rolle, was damit passiert, da es sich nur um einen VALUE handelt und keine Verbindung mehr zum AGGREGATE besteht.

Wenn ein Root-Aggregat einen Verweis auf ein anderes Root-Aggregat enthält, wird die Grenze des ersteren verletzt und das gesamte Konzept eines Aggregats wird beschädigt. Ich glaube also, dass ein Root-Aggregat einen Verweis auf ein anderes Root-Aggregat enthalten muss um eine andere Entität zu erstellen , die wahrscheinlich dieselben Mitglieder wie die andere Stammentität hat, aber keine globale Identität besitzt, wie diese andere Regel im Buch besagt:

Root ENTITIES haben eine globale Identität. ENTITÄTEN innerhalb der Grenze haben eine lokale Identität, die nur innerhalb des AGGREGATES eindeutig ist.

Ich glaube, dies wäre der richtige Weg, aber da er sich wiederholt und überflüssig anfühlt (aus dem DDD-Kontext herausgenommen, mit reinem OOP), bitte ich um Feedback.


Was meinen Sie mit "interner Entität (das ist zufällig die Stammentität in einem separaten Aggregat)"?
Erik Eidt

2
FWIW, Alles kann sich auf eine aggregierte Stammentität beziehen, da dies die Dinge mit globaler Identität sind. ob der Referrer selbst eine Root-Entität ist oder nicht, ist unerheblich.
Erik Eidt

Wie Erik sagte. Außerdem spielt es keine Rolle, ob Sie in Ihrem Modell eine ID oder eine Referenz verwenden. Beide werden auf DB-Ebene in ID konvertiert, und ein Verweis gibt ORM die Möglichkeit, die Entität bei Bedarf faul zu laden.
Euphoric

Antworten:


21

Möglicherweise haben Sie das Buch überinterpretiert. Grundsätzlich heißt es: Alles außerhalb eines Aggregats kann keinen Verweis auf irgendetwas in ihm enthalten, außer auf die Wurzel. Daher ist es legitim, einen Verweis auf eine Wurzel zu haben. Wenn Sie eine Referenz auf eine Wurzel halten, bedeutet dies nicht, dass sie Teil Ihres eigenen Aggregats ist und dass Sie deren Invarianten steuern können. Es behält seine eigenen Invarianten und Autonomie.

Jedoch,

  • Eine allgemein anerkannte bewährte Methode besteht darin, auf einen AR zu verweisen, indem seine ID gespeichert wird, nicht eine vollständige Referenz.
  • Modernere Ansätze für das Design von Aggregaten (siehe das Rote Buch ) befürworten eine sauberere Trennung zwischen Aggregaten. Ein Geschäftsvorgang sollte nur den Status eines einzelnen Aggregats ändern. Unter dieser Annahme verschwindet die Notwendigkeit, einen Verweis auf ein anderes Aggregat zu speichern, in der Regel, da nicht zwei Aggregate gleichzeitig geändert werden.

Ist es richtig, dass ein Stammaggregat einen Verweis auf eine interne Entität enthält, die zufällig die Stammentität in einem separaten Aggregat ist?

Das passiert nie. Ein Wertobjekt kann Teil mehrerer Aggregate sein, jedoch keine Entität. Der Grund dafür ist, nichts würde man dann verhindern , dass die gleiche Person teilt Instanz zwischen Aggregates. Angenommen, die Entitätsinstanz E gehört zu beiden Aggregatinstanzen A und B. Da DDD voraussetzt, dass das Aggregat der Einstiegspunkt ist, können Sie A laden, die Entität E dadurch ändern und dabei unbemerkt Invarianten von verletzen B (dass Sie nicht geladen haben).

Die Antwort von Greg Young finden Sie hier: http://domain-driven-design.3010926.n2.nabble.com/Can-an-Entity-be-Shared-across-many-Aggregates-td7579277.html


Vielen Dank an Guillaume für die klare, präzise und aufschlussreiche Antwort. Ein wahrer DDD-Kenner. Das ist, wonach ich gesucht habe. Chapeau!
Lesair Valmont

Ich weiß, dass es eine dumme Frage sein kann. Aber könnte ich fragen, was holding a referencein diesem Zusammenhang bedeutet? weil ich verwirrt war, als Sie das sagten: holding a reference to a root is legitdanach sagten Sie:This never happens. A Value Object can be part of multiple Aggregates, but not an Entity. The reason is, nothing would then prevent you from sharing the same entity instance between Aggregates.
Anyname Donotcare

1
Halten Sie eine Referenz = halten Sie sie intern / dauerhaft als Mitglied der Klasse. Die Dichotomie lautet hier root vs non-root. Sie können an einer Stammreferenz festhalten, jedoch keine Nicht-Stammreferenz.
Guillaume31

@ guillaume31 vielen Dank, aber könnte ich fragen, ob es in Ordnung ist, eine idinterne Entität (nicht-root) in einem anderen Aggregat zu belassen, oder dies verstößt gegen ob (root oder nicht)?
Anyname Donotcare

Was würden Sie mit diesem Ausweis machen? Selbst Repositorys geben Ihnen nur Wurzeln, keine internen Entitäten.
guillaume31

1

Ihr aggregiertes Stammobjekt sollte (im Allgemeinen) nur Eigenschaften haben, die Teil seiner Domäne sind.

Wenn Sie ein AR-Objekt mit einer Eigenschaft haben, die sich nicht im Aggregat befindet, werden Sie sofort mit der Frage konfrontiert. 'Warum nicht?'

Könnten Sie vielleicht die ID des anderen Objekts hinzufügen? Oder ein Repository injizieren?

Es klingt jedoch so, als ob Sie einen domänenübergreifenden Dienst hinzufügen sollten, der auf beide Stammobjekte verweist und die erforderliche Logik ausführt


Ewan, ich dachte eher daran, eine Klasse zwischen zwei verschiedenen Aggregationen im Sinne von OOP wiederzuverwenden, anstatt einen Domänendienst als Geschäftsskript zu verwenden, der einige Arbeiten mit den beiden verschiedenen DDD-Aggregaten ausführt. Zusammenfassend stimme ich Ihnen zu, dass meine Gesamtwurzel nur Eigenschaften haben sollte, die Teil ihrer Domäne sind.
Lesair Valmont
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.