Ich habe ein Domänenprojekt eingerichtet, das mit einem ORM gefüllt wird. Die Domäne enthält verschiedene Aggregate mit jeweils einem eigenen Root-Objekt. Meine Frage ist, wie Eigenschaften, die die Aggregatgrenzen überschreiten, behandelt werden sollten?
Ein Beispiel:
Kontext A = Benutzer
Kontext B = Spiele
Innerhalb des Kontexts Users befindet sich ein Objekt UserOwnedGames . Dieses Objekt hat eine Eigenschaft User , die eine Referenz auf ein Objekt im selben Users -Kontext ist. Das Objekt hat auch eine Eigenschaft für Game , die offensichtlich nicht in den Benutzern, sondern im Games -Kontext liegt.
Wie würde (oder sollte?) diese Beziehung aussehen? Es ist klar in der Datenbank (dh 2 Fremdschlüssel) aber wie soll der Code aussehen?
Es klingt, als ob Ihr User -Kontext auch eine Game -Entität benötigt. Beachten Sie jedoch, dass dies nicht unbedingt dieselbe Game -Entität ist, die die Wurzel des Game -Kontexts ist. Diese zwei beschränkten Kontexte können unterschiedliche Vorstellungen davon haben, was ein Game ist und welche Eigenschaften es hat. Nur die Identität verbindet die beiden Game-Objekte miteinander.
Sie sollten DB-Referenzen in BCs vermeiden. Sie sollten nicht versuchen, die referenzielle Integrität zwischen Aggregaten aus verschiedenen BCs (Transaktionen) sicherzustellen. Idealerweise sollte die Transaktion nur innerhalb eines einzelnen Aggregats, nicht einmal BC, stattfinden.
Bessere einfache Wertobjekte für IDs - UserId und GameId - verwenden und diese bei Bedarf der Entität zuweisen. Auf diese Weise sind diese "entfernten" Einheiten vollständig getrennt, so dass Sie sich keine Sorgen um ihre Verbindung machen müssen. Die Synchronisierung könnte mithilfe der Messaging-Plattform implementiert werden.
Wenn Sie Freizeit haben, lesen Sie diese wertvollen Artikel (von Vaughn Vernon):
Es hängt davon ab, welche beschränkte Kontext-Strategie Sie verwenden.
Wenn Sie shared kernal wählen, denke ich, dass es in Ordnung ist, eine direkte Beziehung zwischen ihnen zu haben (direkte Referenz oder Bezeichner-Referenz, ich glaube, jemand anderes wird die Vor- und Nachteile in anderen Antworten erklären). und Sie haben auch diese Objekte erwähnt, die von Datenbanktabellen integriert sind.
Aber wenn Sie Anti-Korruptions-Schicht wählen, sollten Sie sie besser trennen (verwenden Sie nur Bezeichner, um die Beziehung beizubehalten), verwenden Sie Adapter-Übersetzer zur Integration (und keine Datenbank-Integration).
Tags und Links domain-driven-design aggregateroot bounded-contexts