Aggregate-Root-Referenzen anderen Aggregatstämme

Derzeit arbeite ich viel mit DDD und ich bin vor ein problem beim laden/Betrieb auf die gesamtwirtschaftliche Wurzeln aus anderen Aggregat Wurzeln.

Für jede Aggregat-Wurzel in meinem Modell, ich habe auch ein repository. Das repository ist verantwortlich für den Umgang mit Persistenz-Operationen für die Wurzel.

Sagen, dass ich zwei Aggregat-Wurzeln, mit einigen Mitgliedern (entities und value objects).

AggregateRoot1 und AggregateRoot2.

AggregateRoot1 hat ein Unternehmen Mitglied, die Verweise AggregateRoot2.

  1. Wenn ich es lade AggregateRoot1, sollte ich laden AggregateRoot2 auch?
  2. Sollte das repository für AggregateRoot2 HIERFÜR verantwortlich sein?
  3. Wenn dem so ist, ist es okay für die Entität in AggregateRoot1 rufen Sie das repository von AggregateRoot2 zum laden?

Auch, wenn ich erstellen Sie eine Assoziation zwischen der Entität in AggregateRoot1 zu AggregateRoot2, sollte das getan werden, durch die Person oder durch das repository für AggregateRoot2?

Hoffe, dass meine Frage Sinn macht.

[BEARBEITEN]

AKTUELLE LÖSUNG

Mit Hilfe von Twith2Sugars, ich habe es mit der folgenden Lösung:

Wie beschrieben in der Frage, aggregatstamm Kinder haben, die Verweise auf andere Wurzeln. Bei der Zuweisung von root2 eines der Mitglieder der root1, das repository für root1 verantwortlich für die Erkennung dieser Veränderungen, und delegieren diese an das repository für root2.

public void SomeMethod()
{
    AggregateRoot1 root1 = AggregateRoot1Repository.GetById("someIdentification");
    root1.EntityMember1.AggregateRoot2 = new AggregateRoot2();
    AggregateRoot1Repository.Update(root1);
}

public class AggregateRoot1Repository
{
    public static void Update(AggregateRoot1 root1)
    {
        //Implement some mechanism to detect changes to referenced roots
        AggregateRoot2Repository.HandleReference(root1.EntityMember1, root1.EntityMember1.AggregateRoot2)
    }
}

Dies ist nur ein einfaches Beispiel, kein Gesetz von Demeter oder anderen bewährten Prinzipien/Praktiken gehören 🙂

Weitere Kommentare dankbar.

  • Persönlich kann ich sehen, ist der derzeitige Ansatz, chaotisch, und ich denke, DavidMasters84 die Lösung ist eher eine elegante Lösung. Ie halten Referenzen als id ' s und extrahieren diese Art der domain-Logik, um einen domain-service.
  • Chaotisch ist ein gutes Adjektiv für diesen Ansatz. Ich darf das sagen, weil ich ursprünglich versucht, die Umsetzung dieses Problems in der gleichen Weise, und ein Durcheinander ist das, was ich fand mich an 🙂 möchten Sie vielleicht zu Lesen hier Anregungen auch für eine ähnliche Frage: stackoverflow.com/questions/2118088/...
  • Ich höre Sie, aber nicht Repositorys, es zu verwalten, aggregieren Wurzeln, und mit einigem guten Willen, die Beziehungen zwischen den Wurzeln. Und domain-Dienste zu handhaben Verhalten, die nicht ganz Natürliche Passform in einer einzigen Einheit? Mir scheint, dass der Domain-Service verantwortlich für die Handhabung von Referenzen zwischen den Wurzeln ist der falsche Ort, wenn das Lesen der definition eines Domain Service... ich könnte falsch sein, also eine mehr gesichert argument würde geschätzt, danke.
  • Mein Vorschlag für einen domain-service gibt es nicht zum verwalten von Referenzen zwischen Aggregaten; es ist dort zum aufrufen von Funktionen, die mehr beinhaltet als eine aggregierte, d.h. "Verhaltensweisen, die nicht natürlich passen in eine Einheit". In den meisten Modellen alle Aggregate beziehen sich auf die jeweils andere in irgendeiner form im Sinne eines relationalen Datenbanken, der Punkt der Aggregate ist zu brechen diese Abhängigkeit Graphen in überschaubaren Gruppen. Wenn Sie gepflegt werden die Beziehungen zwischen allen Aggregaten in das Modell würde sich der Punkt der Aggregate.
  • Yep, das ist ziemlich viel, meine Gedanken auf Sie; auf Ihre Frage über das ausführen von Operationen zwischen der Aggregat-Wurzeln, die ich denke, ist, wo der domain-service passt. Ich denke, bald wirst du dich Fragen, wie tief hat Sie das Kaninchen-Loch geht...
  • tschmuck, ich bin nicht einverstanden mit Ihrer Lösung und Stimmen mit DavidMaster. agg1.DoSomething(agg2); funktioniert gut, wie es ist Garantie aggr1 Objekt-Integrität.
  • Wie ich gelesen habe Ihre Anregung, den Bezug zwischen agg1 und agg2 werden nur vorübergehend sein. Das repository ist verantwortlich für die persistenten Zustand und die Beziehungen zu was auch immer-Mechanismus gewählt. Also, wie würden Sie damit umgehen, dass die Beziehung zwischen aggregate1.Entity --> aggregate2. Ich muss in der Lage sein, wieder den Zustand und die Beziehung. Sind Sie sugessting, dass der Domain-Service, oder das Objekt selbst (agg1) sollte umgehen?
  • Wie kamen Sie auf mit diesem? Es scheint mir, Sie sind gefangen in den Daten Beziehungen statt der geforderten Verhalten. Wenn aggregate1 muss, um es zu ändern ist-Zustand basierend auf aggregate2, braucht er nicht zu halten aggregate2 innerhalb es eigenen Zustand ist, kann es einfach weitergegeben werden aggregate2 über eine Methode auf den Zeitpunkt, wenn die Funktionen aufgerufen werden muß. Es scheint, die meisten Menschen sind einverstanden mit meiner Lösung...

InformationsquelleAutor tschmuck | 2011-02-07
  1. -4

    Vielleicht die AggregateRoot1 repository nennen könnte AggregateRoot2-repository, wenn es den Bau der AggregateRoot1 Einheit.

    Ich glaube nicht, dass diese ungültig ddd, da die repositories sind noch im laden zu bekommen/erstellen eigene Entitäten.

    • Als ich dies auch, aber was ist, wenn Aggregate2 hat einen Verweis auf Aggregate3, und aggregate3 zu einem anderen und so eine. Möglicherweise könnte dies ein ziemlich großes Objekt graph. Was sind die vorgeschlagenen Strategien für diese scenarioes?
    • True, ich weiß, Sie sind eigentlich nicht sorgen zu machen über die Umsetzung zu viel in DDD aber an diesem Punkt Id lazyload der Aggregate, wenn ich dachte, die Grafik ist zu groß.
    • Ok, so weit so gut. 🙂 Aber wenn ich es Schaffe die Beziehung zwischen AggregateRoot1.Entity1 --> AggregateRoot2, soll dies über die AggregateRootRepository1.AddRoot2ToEntity1(root1, root2) oder durch AggregateRepository2.AddRoot2ToRoot1(root1, root2) oder eine direkte Zuweisung: root2.Entity1.AddRoot2(root2)
    • Ich persönlich würde sagen, keines von Ihnen. Ich würde ordnen Sie es über diesen: "entity1.Entity2 = entity2" und dann das repository sollte in der Lage sein, zu erkennen, diese Beziehung und tun, was immer er tun muss, (D. H. aktualisieren, die db-Spalte, wenn das ist der zugrunde liegende Speicher)
    • Danke TWith2Sugars, aber ich würde wirklich gerne noch etwas mehr feedback, bevor ich schließe diese Frage. Ich Schätze Ihre Antworten-
    • Kein problem,£: -)
    • Ich denke, deine Lösung mit dem repository verantwortlich für die Erkennung von änderungen in relationsships zu anderen Aggregat Wurzeln, ist ein schön und sauber. Das repository Delegierten änderungen an referenzierten Wurzeln, um das entsprechende repository, und diesem repository arbeiten können, in ein smiliar Weg und delegieren Sie an andere als gut (in großen Graphen, wenn man bedenkt lazy loading). Ich Bearbeiten meine Frage, wie würde ich es implementieren, und Ihnen Kredite für die Antwort. Danke

    InformationsquelleAutor TWith2Sugars
  2. 57

    Habe ich in dieser situation gewesen, mich selbst und kam zum Schluss, dass es ist zu viel Kopf Schmerzen zu machen, Kind Aggregate arbeiten in einer eleganten Art und Weise. Stattdessen würde ich überlegen, ob Sie wirklich brauchen, um-Referenz das zweite Aggregat, als Kind der ersten. Es macht das Leben viel einfacher, wenn Sie nur immer eine Referenz auf das Aggregat ID-anstatt die eigentliche Aggregat selbst. Dann, wenn es die domain-Logik beinhaltet, dass die beiden Aggregate dieser extrahiert werden kann, um einen domain-service und Aussehen etwas wie dieses:

    public class DomainService
{
    private readonly IAggregate1Repository _aggregate1Repository;
    private readonly IAggregate2Repository _aggregate2Repository;

    public void DoSomething(Guid aggregateID)
    {
        Aggregate1 agg1 = _aggregate1Repository.Get(aggregateID);
        Aggregate2 agg2 = _aggregate2Repository.Get(agg1.Aggregate2ID);

        agg1.DoSomething(agg2);
    }
}

    EDIT:

    Ich WIRKLICH empfehlen, dieser Artikel zum Thema: https://vaughnvernon.co/?p=838

    • + 1. Das ist auch das, was Vaughn Vernon argumentiert in seinem "Referenz-Andere Faktoren Von Identität" - Regel. Die Vorteile sind das Aggregat der Größe was zu einer besseren Leistung und einfacher zu partitionieren. Der Nachteil, die ich denke, ist, dass es irgendwann macht das Modell code weniger ausdrucksstark, es ist also ein trade-off wie gewohnt: dddcommunity.org/sites/default/files/pdf_articles/...
    • Mit diesem Ansatz sind Sie nicht das speichern der Beziehung zwischen Aggregate1 und Aggregate2 in db, was werden Sie tun, wenn die Anforderung besteht, sich daran zu erinnern, dass die Beziehung
    • Ja, Sie sind. In dem obigen Beispiel, Aggregate2 speichert die ID der zugehörigen Aggregate1.
    • ok ich sah, dass jetzt, aber was u nicht lassen, die db zu pflegen tat Beziehung in der obigen code-Zeile Aggregate2 agg2 = _aggregate2Repository.Get(agg1.Aggregate2ID); wir wissen nicht, ob 'Aggregate2ID' existiert oder nicht?
    • um ehrlich zu sein ich weiß wirklich nicht, was du sagst. Ob eine Klasse eine ID-Eigenschaft, vollständige Objekt-Referenz, oder gar nichts, hat keinen Einfluss darauf, wie diese Beziehung gepflegt werden, in der Datenbank als Fremdschlüssel.
    • sorry wenn ich nicht klar war, meine Verwirrung war, da es sich nicht um eine vollständige Objekt-Referenz, ob es noch ein FK Bezug auf db-Ebene, ich dachte mehr Umsetzung hier. Also ich denke, das, was u r eigentlich sagen lassen, es werden keine Verknüpfungen, sondern die Tische haben eine FK definiert. Die Anwendungsschicht entscheiden sollte, wenn es benötigt das ganze Objekt aus der Id, in dem Fall fragt es das repository mit der Id
    • ja, das ist im Grunde, was ich sage. P. S. ich kann nicht genug empfehlen den link, den Dmitri in seinem Kommentar. Diese PDF ' s bieten die beste Erklärung, die in Aggregat-design, das ich gelesen habe.
    • +1. Vielen Dank für Ihren link zu den großen DDD-Artikel! 🙂
    • der link ist tot, wissen Sie, wenn Sie die PDF-Dateien sind um anderswo?
    • href="http://dddcommunity.org/library/vernon_2011/" >dddcommunity.org/library/vernon_2011
    • vielen Dank - die Artikel sind genial!
    • Der links ist tot. Wer weiß, wo finde ich die pdf?
    • href="https://vaughnvernon.co/?p=838" >vaughnvernon.co/?p=838
    • Ich habe nur eine Sache zu Fragen, wenn ich Produkt-Aggregat und BackLogItems Aggregat , und wo BackLogItem auf das Produkt von Identität.Je nach Ihrem Verständnis könnte ich backLogItem.DoSomeInvaraintsChecking(Produkt); zum Beispiel kann ich nicht planen, neue BackLogItem im Falle das Produkt ausgesetzt ist.
    • Wenn ich mich nicht verwirren, es ist ein anemic domain model wrap up die tatsächliche reiche Domäne ist es nicht?

    InformationsquelleAutor David Masters
Schreibe einen Kommentar