So modellieren Sie die Sortierreihenfolge für viele zu eins über zwei aggregierte Wurzeln hinweg

Question

Übernehmen Sie die vorgeschlagene Domain Effektives Aggregatdesign eines Produkts, das mehrere Releases hat.In diesem Artikel kommt Vaughn zu dem Schluss, dass sowohl das Produkt als auch die Veröffentlichung jeweils eigene Gesamtwurzeln sein sollten.

Nehmen wir nun an, dass wir eine Funktion hinzufügen

• Als Release Manager Ich möchte es können Veröffentlichungen sortieren so dass Ich kann Zeitpläne für die Bereitstellung größerer Epics für unsere Benutzer erstellen

Ich bin kein PM mit einem besonderen Bedarf, aber es scheint vernünftig, dass sie die Möglichkeit haben möchten, Veröffentlichungen in der Benutzeroberfläche zu sortieren.

Ich bin mir nicht ganz sicher, wie das funktionieren soll.Es ist selbstverständlich, dass jedes Release eine Bestelleigenschaft hat, aber eine Neubestellung würde die Änderung mehrerer Aggregate in derselben Transaktion erfordern.Wenn diese Informationen andererseits im Produktaggregat gespeichert werden, benötigen Sie eine Methode wie product.setRelaseOrder(ReleaseId[]) Das scheint ein seltsames Datenstück zu sein, das an einem völlig anderen Ort als Releases gespeichert werden muss.Schlimmer noch: Das Hinzufügen einer Version würde wiederum Änderungen an zwei verschiedenen Aggregaten erfordern!Was können wir sonst noch tun?ProductReleaseSortOrder kann ein eigenes Aggregat sein, aber das klingt geradezu absurd!

Was also tun?Im Moment neige ich immer noch zur Option „Produkt verwalten lassen“, aber was ist hier richtig?

Answer 1

Also, Produkt und Freisetzung sind beide Ars.Release hat eine Verbindung zum Produkt über Aggregateid.Sie möchten die Liste aller Releases für ein bestimmtes Produkt erhalten, das von etwas bestellt wurde?

Da die Bestellung ein Attribut von Aggregat ist, sollte es auf dem Produkt eingestellt werden, aber Releases sind ARS auch und Sie sollten nicht auf das Repository der Freigabe in Produkt AR zugreifen (jeder AR sollte sein eigenes Repository haben).

Ich würde einfach einen ReleaseQueryService erstellen, der den Parameter produziert und bestellen und relaxeErEpository-Parameter anruft.

Ich würde auch über die Trennung von Kontexten nachdenken, vielleicht sollte das Modell für die Freigabepräsentation in einem anderen Kontext sein?In Beispiel zusätzliche AR-Produktreserve, die nur zum Abfragen verwendet werden würden.

Answer 2

Ich habe festgestellt, dass es tatsächlich am besten ist, eine zu erstellen neu Aggregatwurzel (z. B. ProductReleaseSorting wie vorgeschlagen) für jeden einzelnen Sortier- und/oder Bestellzweck.Das ist weil releaseOrder ist offensichtlich nicht wirklich eine Eigenschaft des Product, d. h. etwas, das für sich genommen eine Bedeutung für ein Produkt hat.Vielmehr handelt es sich tatsächlich um eine Eigenschaft einer „Ansicht“ auf a Sammlung von Produkten, und diese Sichtweise sollte eigenständig modelliert werden.

Der Grund, warum ich dazu neige, für jede einzelne Ansicht einer Artikelsammlung einen neuen aggregierten Stamm einzuführen, wird deutlich, wenn Sie darüber nachdenken, was passiert, wenn Sie in Zukunft zusätzliche Bestellungen einführen würden, beispielsweise einen „Marketingauftrag“ oder mehrere Produktmanager möchte seine eigene Bestellung behalten usw.Hier erkennt man leicht, dass es sich bei „Marketingauftrag“ und „Freigabeauftrag“ um zwei unterschiedliche Konzepte handelt, die unabhängig voneinander behandelt werden sollten. Wenn mehrere Personen die Produkte mit demselben Schlüssel, aber unterschiedlichen Bestellungen bestellen möchten, benötigen Sie individuelle „ Aufrufe pro Person".Darüber hinaus könnte es sein, dass es mehrere Reihenfolgekriterien gibt, die man bei der Sortierung berücksichtigen möchte (ein Beispiel für Letzteres wäre (in einem anderen Kontext) schnellste Route vs.(kürzester Weg), was alles von der Ansicht abhängt, die Sie auf die Sammlung haben, und nicht von den einzelnen Eigenschaften ihrer Elemente.

Wenn Sie nun die Sortierung des Produktmanagers in a übernehmen ProductReleaseSorting Aggregat, du

1. eine einzige Quelle der Wahrheit zur Unterstützung der Bestellung haben (die AR),
2. Die ProductReleaseSorting AR kann Einschränkungen erzwingen, z. B. dass keine zwei Produkte die gleiche Bestellnummer haben dürfen, und zwar Sie
3. stehen Sie nicht vor dem Problem, bei einer Auftragsänderung mehrere ARs in einer einzigen Transaktion aktualisieren zu müssen.

Beachten Sie, dass Ihr ProductReleaseSorting Das Aggregat hat höchstwahrscheinlich eine eindeutige Identität („Singleton“) in Ihrer Domain, d. h. alle Produktmanager teilen die gleiche Sortierung.Wenn jedoch alle Teammitglieder gerne ein eigenes haben würden ProductReleaseSorting, es ist trivial, dies durch die Angabe zu unterstützen ProductReleaseSorting eine entsprechende ID.Ebenso ein allgemeinerer ProductSorting kann über eine Team-ID abgerufen werden (Marketing vs.Produktmanagement) aus dem Repository.All dies ist mit einem neuen, separaten Aggregatstamm für Bestellzwecke einfach, aber schwierig, wenn Sie Eigenschaften zu den zugrunde liegenden Elementen/Entitäten hinzufügen.