Wie arbeite ich mit großen aggregierten Wurzeln?

Ich lerne DDD und habe dennoch mehr Fragen als Antworten.

Betrachten wir ein Modell eines Verzeichnisses mit einer enormen Anzahl von Dateien.
So sehe ich das:

Das Verzeichnis ist eine aggregierte Wurzel.
Diese Entität sollte über die Validierungslogik verfügen, die Eindeutigkeit des Dateinamens zu überprüfen, wenn sie hinzugefügt oder nur umbenannt wird. Die Dateientität enthält die Logik 'SetName', mit der Directory über Domain Event über Namensänderungen informiert wird.
Aber wie soll Directory dann funktionieren?
Es ist nicht immer möglich, alle Dateien in den Speicher zu laden. Sollte das Datei-Repository in diesem Fall über eine Ad-hoc-Logik zur Überprüfung der Eindeutigkeit von Namen verfügen? Ich nehme an, es ist eine tragfähige Entscheidung.
Was ist jedoch, wenn einige Dateien bereits mit der aktuellen, noch nicht festgeschriebenen Transaktion hinzugefügt oder umbenannt wurden? (Nichts verbietet dies. Transaktionsgrenzen werden extern in Bezug auf die Geschäftslogik festgelegt.) Wahrscheinlich sollte das Repository sowohl speicherinterne als auch persistierte Zustände berücksichtigen (das Zusammenführen dieser Zustände kann eine nicht triviale Aufgabe sein.)

Wenn also die Gesamtwurzel mit all ihren Kindern in die Erinnerung passt, ist alles in Ordnung. Und sobald Sie nicht alle Entitäten materialisieren können, gibt es Probleme.

Ich würde gerne wissen, wie die Ansätze für solche Situationen aussehen. Vielleicht gibt es überhaupt kein Problem und es liegt nur an meinem Missverständnis des Themas.

Meine Antwort ist voreingenommen mit Vaughn Vernons großartigem Buch "Implementing Domain Driven Design" (ein Muss)

1. Bevorzugen Sie kleine Aggregate.

Wenn ich Ihre Domain modellieren möchte, würde ich eine Directoryals Aggregat und Fileals ein anderes Aggregat modellieren .

2. Referenzaggregate nach IDs.

Daher Directorywird eine Sammlung von FileIdWertobjekten haben.

3. Verwenden Sie Fabriken, um Aggregate zu erstellen.

Für einen einfachen Fall kann eine Factory-Methode ausreichen Directory.addFile(FileName fileName). Für komplexere Fälle würde ich jedoch eine Domain Factory verwenden.
Die Domänenfactory kann fileNamemithilfe eines FileRepositoryund eines UniquefileNameValidatorInfrastrukturdienstes überprüfen, ob dies eindeutig ist .

Warum Fileals separates Aggregat modellieren ?

Weil Directoriesnicht gemacht sind Files. a Fileist mit einem bestimmten verbunden Directory. Stellen Sie sich auch ein Verzeichnis mit Tausenden von Dateien vor. Das Laden all dieser Objekte in den Speicher jedes Mal, wenn ein Verzeichnis abgerufen wird, ist ein Leistungskiller.

Modellieren Sie Ihre Aggregate gemäß Ihren Anwendungsfällen. Wenn Sie wissen, dass ein Verzeichnis niemals mehr als 2-3 Dateien enthält, können Sie sie alle als ein einziges Aggregat modellieren. Nach meiner Erfahrung ändern sich die Geschäftsregeln jedoch ständig und es lohnt sich, wenn Ihr Modell flexibel genug war, um die Anforderungen zu erfüllen Änderungen.

Obligatorische Lektüre Effective Aggregate Design von Vaughn Vernon

Dies ist per se keine DDD-Frage. Die Hauptfrage hier ist über den Synchronisationskontext (der hier eine aggregierte Wurzel ist).

Zurück zum Thema: Das Verzeichnis soll ein Synchronisationsobjekt mit Dateinamen blockieren und prüfen, ob der angegebene Dateiname zulässig ist, der im schlimmsten Fall O (n) ist.

Obwohl einige sagen mögen, dass Sie versuchen, Ihr Design zu ändern, besteht immer ein Bedarf, wenn ein AR eine große Liste einfacher Objekte enthält. Und das Speichern im Speicher ist aus Sicht der Leistung nicht das Beste. In solchen Fällen müssen Sie jedoch nur die Transaktionsgrenzen beibehalten. Eine einfache Lösung ist die folgende:

1. Halten Sie den AR des Ordners einfach und fügen Sie eine Versionsspalte ein.
2. Lassen Sie jede Datei (sagen wir Zeile) auf das aggregierte Stammverzeichnis verweisen, mit anderen Worten, um die ID des Ordners beizubehalten.
3. Führen Sie die Änderungen der Dateien, z. B. Umbenennen, Hinzufügen, Entfernen, immer über den AR durch. Mit anderen Worten, wenn Sie eine Datei hinzufügen möchten, laden Sie den AR und verwenden Sie eine Methode in AR, um die Änderung vorzunehmen. Angenommen, Sie verwenden ein Repository-Muster, erstellt addFile () eine neue Datei und ändert die Version des Ordners. Speichern Sie diese als UoW. Wenn jemand anderes den AR geändert hat, wird aufgrund der Versionsspalte (der AR-Version) ein Fehler angezeigt.
4. Jede Änderung an der Datei selbst, wie das Bearbeiten oder Umbenennen der Datei, sollte über den AR erfolgen. Die Version bleibt also im AR. Dies bedeutet im Wesentlichen, dass es in Ihrem Code keine anderen Ausführungspfade gibt, die die Datei ändern, außer dem besitzenden AR.

Einige Einschränkungen:

1. Die Datei sollte nur zu einem AR gehören. Ist dies nicht der Fall, modellieren Sie die Beziehung von Ordner -> Datei als Containment und nicht die Datei selbst.
2. Sie können eine Datei nicht von einem Ordner in den anderen verschieben, es sei denn, Sie nehmen diese Änderung in einer UoW ​​vor, dh in derselben Transaktion. Dies ist ein Sonderfall, da Sie eine Anfrage senden sollten, die in zwei Befehlen endet, sodass beide ARs geändert werden, daher jeweils zwei neue Versionen und wahrscheinlich zwei Ereignisse (Datei entfernt, Datei hinzugefügt), und dies ist ein bisschen schwierig, weil Sie die Ereignisreihenfolgen für die beiden ARs pflegen sollten, was manchmal nicht einfach ist.