DDD: Wie viele Aggregatwurzeln brauche ich?

Question

Ich bin ein wenig verwirrt mit dem Konzept der Aggregatwurzel in DDD. Die Theorie sagt dann, es sollte eine aggregierte Wurzel sein, die für die aktuelle Operation relevant ist.

Zum Beispiel habe ich ein root-Konto, das eine Firma darstellt. Es hat Adresse, Benutzer, die zu dem Konto gehören, einige andere Eigenschaften.

Und ich habe mehrere Seiten; Eine davon ist die Verwaltung von allgemeinen Informationen wie Name, E-Mail, Telefon ... Eine weitere Möglichkeit besteht darin, Adresse zu verwalten. Eine weitere, um alle Benutzer anzuzeigen (und bearbeiten Benutzerinformationen, die wahrscheinlich auch unter Account-Objekt ist)

Im ersten Fall ist mir egal, Adresse, in der zweiten ist mir egal, Name, E-Mail .. ..

Benötige ich zwei separate Account-Objekte oder brauche ich nur einen Account? (Das Modell kann komplizierter sein, als ich es beschrieben)

So zum Beispiel ich mit Klassen kann am Ende: BasicAccountInformation, AccountAddress, AccountUsers .... Oder nur ein einziges: Konto, das alle Daten enthält?

Was ist der richtige DDD-Ansatz? Was ich denke, in einem Fall werde ich eine sehr komplexe Klasse bekommen, die viele Eigenschaften und Logik enthält; oder viele einfache Klassen mit 2-10 Eigenschaften pro Klasse.

Answer 1

Wie viele Aggregatwurzeln brauche ich?

Mindestens eine.

Aggregate dienen als Konsistenzgrenzen. Wenn Sie Ihre gesamte Domäne als einzelnes Aggregat modellieren und ein "aggregiertes Stammverzeichnis" bereitstellen, das sicherstellt, dass Ihre Geschäftsinvariante von jedem Schreibvorgang beibehalten wird, können Sie loslegen.

Nun, Sie sind gut, langsam zu gehen. Das aggregierte Stammverzeichnis dient als eine Art Serialisierungsengpass für den gesamten Status in der Aggregatgrenze. Wenn Sie erwarten, zwei verschiedene Teile des Modells "zur gleichen Zeit" zu aktualisieren, müssen Sie die Verantwortung für die Geschäftsinvariante partitionieren.

Und ich habe Seiten; Eine davon besteht darin, allgemeine Informationen wie Name, E-Mail, Telefon usw. zu verwalten.

Berichte sind großartig. Sie sagen Ihnen, welche Daten Sie für Ihr Modell sammeln müssen.

Aber Berichte sind miserabel zu sagen, wo Ihre Aggregate sind - die primäre Sorge Ihrer Aggregate ist nicht lesen/präsentieren/melden Sie Ihre Daten, aber schreiben Sie es.

Sie finden Aggregate, indem Sie Daten zu Ihrem Modell finden, die Sie gruppiert zusammenführen müssen, wenn Sie eine schreiben schreiben. Welche Daten benötigen Sie, um die Geschäftsinvariante durchzusetzen?

Diese Heuristik saugt CRUD-Domänen an, weil der größte Teil des Zustands Ihres Modells unabhängig vom Rest ist.

Sie können Entitätsbeziehungen betrachten; Wenn zwei Aggregate eine Entität "teilen", gehört diese Entität wahrscheinlich zu einem dritten Aggregat.

Eine andere Sache, die Sie betrachten können, ist Entity Life Cycles. Wenn eine untergeordnete Entität den aggregierten Stamm überleben kann, wissen Sie, dass Sie es falsch modelliert haben.

Basierend auf dem, was Sie beschreiben, hilft das auch nicht viel hier; Sie haben effektiv Konto und eine Menge Dinge, die darin leben.

Manchmal schlägt alles fehl, und Sie verwenden die Heuristik "Welche Daten möchte ich nur hin und wieder laden", und Sie knacken es einfach in einen Schlüsselwertspeicher und kehren zum Geschäftswert zurück.