Design Aggregation Root ordnungsgemäß

Ich habe einige Probleme beim Entwerfen der Aggregatwurzel. Hier ist, wie ich es in meinem Kopf sehe :)Design Aggregation Root ordnungsgemäß

Jetzt basierend auf dieser mein Aggregat Wurzel wäre der Laden. Aber wenn ich jetzt ein Repository erstellen würde, würde es ungefähr so aussehen?

public class StoreRepository() 
{ 
    Store GetById() {...} 
    StoreZone GetZone() {...} 
    List<StoreZoneStyle> GetStylesByZone() {...} 
    List<Color> GetColorsByStyle() {...} 
}

Ist das ein guter Weg, um fortzufahren? Unnötig zu sagen, dass ich DDD neu bin.

Quelle

2009-10-28 vikasde

Ich denke, Sie müssen die Aggregatgrenzen und die Entitäten als etwas mehr als nur eine Hierarchie betrachten. Wahrscheinlichkeiten sind, Sie haben ein reicheres Modell als das.

Die erste Möglichkeit zu sagen, ob Ihr Aggregat richtig ist, besteht darin, dass Sie sich die einzelnen Entitäten ansehen und fragen können: "Muss direkt darauf zugegriffen werden?" Wenn Sie mit Ja antworten, ist diese Entität wahrscheinlich nicht Teil des Aggregats.

Ohne mehr über Ihre Domain zu wissen, könnte ich annehmen, dass Store tatsächlich ein Aggregat ist. Der Verkauf ist dagegen komplexer. Ja, der Verkauf erfolgt in einem Geschäft, aber müssen Sie selbst einen Verkauf verwenden? Wenn Sie sie außerhalb des Umfangs der Arbeit mit einem Geschäft benötigen, liegt Sales wahrscheinlich außerhalb dieses Aggregats.

Ich stelle mir vor, dass sowohl Stile als auch Farben unveränderlich und wiederholbar sind, so dass sie in diesem Fall wahrscheinlich Wertobjekte wären. Sind Zonen in einem Geschäft einzigartig oder variieren sie?

Persönlich finde ich Wert beim Identifizieren aller Elemente in der Domäne auf Papier (oder Whiteboard). Ich werde mit dem Stakeholder eine Entdeckungsphase machen und sie einfach rausbringen. Verwenden Sie diese Wörter dann als Anführer in der Konversation und versuchen Sie zu verstehen, wie sie sich verhalten. Wenn Sie den Stakeholder gut genug interviewen, wird die Beschreibung, die er/sie gibt, tatsächlich das meiste von dem definieren, wonach Sie suchen.

Nicht um ein totes Pferd zu schlagen, aber das Evans-Buch ist definitiv wert, gelesen/gelesen zu werden. Es ist ein wenig trocken, aber sehr aufschlussreich. Für einen schnellen Jumpstart können Sie die free book auf InfoQ lesen, die im Grunde eine Zusammenfassung des Evans Buches ist.

Quelle

2009-10-28 20:22:15

Ja, ich möchte auch direkt auf die Verkäufe zugreifen, wahrscheinlich indem ich einfach die StoreId übergebe. Ich denke, ich würde in diesem Fall ein SaleRepository erstellen? Zonen variieren je nach Geschäft.Jedes Geschäft kann separate x Anzahl von Zonen haben. Würde ich hier auch ein ZoneRepository erstellen? Ich bestellte evans book, würde aber schon anfangen meine Domain zu recherchieren. Bitte lassen Sie mich wissen, wenn Sie weitere Informationen benötigen. Je mehr Wissen ich bekomme, desto besser werde ich DDD verstehen. Danke noch einmal. – vikasde

Aggregate Grenzen sind meiner Meinung nach wahrscheinlich die schwierigste Sache in DDD. Wenn Sie eine Store-ID in ein vorgeschlagenes Verkaufsrepository eingeben müssen, gibt es zwei Möglichkeiten, die sofort verfügbar sind. Erstens könnte Sales Teil des Store-Aggregats sein, das Sie erwähnt haben. Der andere könnte sein, dass ein Store Teil eines Sales-Aggregats sein könnte. Die einzige Art und Weise, wie sie wirklich beide Aggregate wären, wäre, wenn Sie beide unabhängig voneinander und ohne direkte Kenntnisse voneinander zugreifen müssten. Beachten Sie, dass Sie nicht davon abgehalten werden .... –

... einen Verweis auf einen anderen Aggregatstamm zu halten. Wenn Sie beispielsweise festgelegt haben, dass Store und Sales aggregierte Stammdaten sind, verhindert nichts, dass ein Sale einen Verweis auf eine Store-ID hat, mit der Sie das Store-Repository aufrufen können, um den Store bei Bedarf zu erhalten. Bezüglich der Zonen gibt es eine eindeutige Beziehung zum Laden. Dies verstärkt den Fall, dass Store * ein aggregierter Root und Zone eine Entity ist (da sie in dem von Ihnen beschriebenen Kontext nicht unbedingt unveränderlich sind). Also, jetzt sind wir sicher, dass Store ein Aggregat ist, das Zonen enthält ... –

Es scheint, dass "Store" nicht aggregiert root ist, weil Sie nicht alle Funktionen für "Zonen", "Sales" usw. hinter "Store" -Objekt verbergen wollen. Auf diese Weise ist das "Store" -Objekt möglicherweise sehr aufgebläht.

"Store", "Zone" und "Verkauf" könnte ein eigenes Repository haben.

Quelle

2009-10-28 20:17:50

Wäre es nicht aufgebläht, ein Repository für jedes Objekt zu haben? Immerhin sind sie alle mit dem Store verbunden, richtig? – vikasde

Wenn für jedes Objekt ein Repository vorhanden ist, wird es nicht aufgebläht. Sie sind kleinere und verständlicher Objekte (Single Responsible Principle). Wenn Sie eine Basisklasse für das Repository haben (Repository ), dann ist es noch weniger Code schreiben. Auf diese Weise müssen Sie wahrscheinlich nur spezielle Abfragen für diese Entitäten schreiben. –

Aggregatwurzeln sind Konsistenzgrenzen für Transaktionen, Verteilungen und Nebenläufigkeit (Eric Evans via Gojko Adzic).

Wenn zwei Personen unterschiedliche Zonen im selben Store ändern, sollte dies zu einem Parallelkonflikt führen? Wenn nicht, sollten Zonen möglicherweise ihre eigene Gesamtwurzel sein, die von Stores getrennt ist.

Quelle

2011-02-12 04:14:30

Design Aggregation Root ordnungsgemäß

Antwort

Verwandte Themen