Verwenden eines Repository innerhalb eines anderen

Question

Ich bin neu in DDD, ich habe ein Partner-Aggregat, das eine Benutzerreferenz hat. Das Benutzerobjekt selbst ist ein weiteres Aggregat.

Da nicht alle Benutzer im Partner-Objekt referenziert werden müssen, ist das User-Objekt ein aggregierter Root. Der Partner ist auch eine aggregierte Wurzel.

Erstens: Würde mein Entwurf mit einer Gesamtwurzel innerhalb einer anderen falsch sein?

Zweitens: Wenn das Design richtig ist, wäre es eine schlechte Praxis, ein Repository in einem anderen zu verwenden, um den Partner zu behalten? (UserRepository in PartnerRepository)

Obs: Ich verwende kein ORM-Framework.

Answer 1

Ich bin neu in DDD ...

Ich werde dies von einem DDD Standpunkt werden antworten, nicht OOP (Objektorientierte Programmierung).

Erstens: Wäre mein Entwurf falsch mit einer Aggregatwurzel innerhalb anderen?

Es würde nicht den allgemeinen Richtlinien des Domain-Driven Design folgen. Wenn Sie eine Aggregatwurzel von einer anderen Wurzel referenzieren möchten, würden Sie sie nach ID referenzieren.

Zweitens: Wenn das Design richtig ist, wäre es eine schlechte Praxis, ein Repository in einem anderen zu verwenden, um den Partner zu behalten?(UserRepository innen PartnerRepository)

Auch wenn nach den Richtlinien von DDD, Sie würden dies nicht tun, würden Sie jedes Aggregat anhalten getrennt über separate Repositorys.

Here's a link to an article by Vaughn Vernon, möglicherweise die zweitgrößte Figur auf dem Gebiet der DDD besser zu erklären.

Answer 2

Erstens: Wäre mein Entwurf falsch mit einer Aggregatwurzel innerhalb anderen?

Ich bezweifle es. Zum Beispiel User kann Benutzerverwaltung und UserProfile das Aggregat Wurzel einer anderen Domäne genannt Benutzerprofile, und wahrscheinlich sollte es eine 1:1 Assoziation zwischen den beiden Domänenobjekte werden so genannte Aggregat Wurzel einiger Domäne sein.

Zweitens: Wenn das Design richtig ist, wäre es eine schlechte Praxis, ein Repository in einem anderen zu verwenden, um den Partner zu behalten? (UserRepository innen PartnerRepository)

Sie sollten sicherstellen, dass es eine klare Trennung von Bedenken, und Sie folgen dem einzige Verantwortung Prinzip. Das heißt, ein Repository kann ein einzelnes Domänenobjekt verarbeiten, und das Einbetten eines Repositorys in ein anderes öffnet die Tür, um verwandte oder nicht verwandte Domänenobjekte zu behandeln.

Mein Rat ist, Sie sollten Transaktionen in Ihren Domain-Services darstellen, und dort können Sie so viele Repositories injizieren, wie Sie benötigen.

Answer 3

Erstens: Wäre mein Entwurf falsch mit einer Aggregatwurzel in einer anderen?

Ja.

AGGREGATE Ein Cluster von zugeordneten Objekten, die als Einheit zum Zwecke der Datenänderungen behandelt. Externe Referenzen sind auf ein Mitglied des Aggregats beschränkt, das als Root bezeichnet wird. Eine Reihe von Konsistenzregeln gilt innerhalb der Grenzen des Aggregats.

Eric Evans, Domain Driven Design

Das Problem Ihr Design ist diese Gesichter: das Aggregat Partner kann seine eigene invariant nicht schützen, wenn der Nutzer Aggregat unabhängig den gleichen Zustand ändern darf.

Wenn in Ihrem Design, Sie behaupten, dass X ein Aggregat ist, zwei Ansprüche machen

1. Die Gültigkeit der zu X Änderung kann ohne Rücksprache mit beliebigen externen Zustand bestimmt werden.
2. Die Gültigkeit einer externen Änderung kann ohne Rücksprache mit dem Zustand von X.

Das ist die Gesamtgrenze bestimmt werden - auf der Außenseite Änderungen nicht nach innen schauen müssen, innerhalb Änderungen müssen nicht Schau hinaus.

Daher ist das Verschachteln von Aggregaten ein Widerspruch. Eine andere Möglichkeit, die gleiche Idee auszudrücken: Wenn ein Aggregatstamm in einem anderen ist, dann haben Sie ein Aggregat (das Partneraggregat), das zwei Wurzeln (die Partnerentität und die Benutzerentität) hat, was genau ist die Situation, die das Gesamtmuster vermeiden soll.

Mögliche Abhilfen:

Einer ist, dass der Nutzer Einheit wirklich Teil des Partner Aggregat ist. Jede Änderung an dem Benutzer soll vom Partner verwaltet werden. Sie verschieben den Benutzer zurück in das Partneraggregat und verhindern, dass Ihre Implementierung darauf zugreift, außer indem Befehle an den Aggregatstamm gesendet werden.

Eine andere ist, dass der Benutzer Einheit nicht Teil des Partneraggregats ist. Dann eliminieren Sie die direkte Referenz im Partner; dies kann bedeuten, dass die Referenz vollständig entfernt wird (wenn die Geschäftsregeln von Partner überhaupt nicht vom Benutzer abhängig sind) oder dass ein Verweis auf die Benutzer-ID und Geschäftsregeln vorhanden ist, die die ID überprüfen, ohne ihr zu folgen (mit anderen Worten: Ihre Regeln überprüfen möglicherweise, ob eine ID-Referenz null/nicht null ist oder/ist kein Mitglied einer Sammlung.Wenn Sie darüber nachdenken, kann das Partneraggregat nicht einmal feststellen, ob der Benutzer, auf den es verweist, existiert.

Ein dritter Punkt ist die Entdeckung einer neuen Entität in Ihrem Modell, die den Teil des Benutzers enthält, den das Partneraggregat tatsächlich für die Validierung verwendet. Dies könnte eine Momentaufnahme des Benutzerstatus sein, oder es könnte ein Refactoring des Benutzers in mehrere Teile sein.