Bestimmung der Repository und aggregieren Größe und Verantwortung in DDD-Architektur

Question

Eine konkrete (ich hoffe) Frage, die ich würde gerne eine konkrete Antwort auf, wenn möglich ... in Bezug auf DDD-Architektur von Aggregaten und Repository Verantwortung und feinkörnigen Ebene.

Lets sagen, ich habe folgende (vereinfachte) Tabellen:

• Kunde [id, name, groupId, categoryId]
• customerGroup [id, name]
• customerCategory [id, name]

Basisfunktionalität (nur Beispiel für die Verwendung von Methoden zu zeigen)

Kundenliste anzeigen und klicken, um einen Kunden anzuzeigen. Bearbeiten Sie den Kunden und wählen Sie die Gruppe aus einer Dropdown-Liste aller Gruppen. Und das gleiche für die Kategorie.

Frage

Sollte halte ich Kundengruppe und Kategorie als separate Aggregate mit:

• CustomerRepository. Mit den Methoden GetAllCustomers, GetCustomerById usw.

• CustomerGroupRepository. Mit Methoden GetAllCustomerGroups, GetOneCustomerGroup

• CustomerCategoryRepository. Mit Methoden GetAllCustomerCategories, GetOneCustomerCategory

Oder nur ein Repo - CustomerRepository (mit allen oben genannten Methoden, mehr explizit genannt).

Ebene oben wird entweder ein CustomerService mit einem/vielen repos oben injiziert werden.

Ich würde gerne etwas über die Frage nach der Größe von Aggregaten und verwandten Daten (Kategorien, Gruppen) mit Vor- und Nachteilen von feinkörnigen Repositories oder nicht. Trotzdem bleibt es einfach und konzentriert sich darauf, Probleme auf eine gute Art und Weise zu lösen, ohne die Dinge zu überarbeiten.

Ich habe versucht, ähnliche Beispiele hier auf SO zu finden und auch Vaughn vernons Artikel zu lesen, aber habe nicht zum Beispiel gesehen, wie sein Beispiel von Produktaggregat Produktkategorien gehandhabt hat.

Answer 1

Kann ein Benutzer eine Kategorie erstellen, in der sich keine Kunden befinden? Wenn Sie mit "Ja" antworten, lautet die Kategorie "root aggregate" und sollte ein eigenes Repository haben.

Gleiches gilt für Kundengruppen. Wenn sie nur eine Art von Wert sind, mit dem Sie den Kunden kennzeichnen, handelt es sich um ein Kindaggregat (oder eher ein Wertobjekt, vergleichen Sie mit Tags). Wenn Sie in der Lage sein sollten, Gruppen unabhängig zu erstellen und dann Kunden an sie anzuhängen, sollten Sie sie als Root-Aggregat definieren.

Answer 2

Es gibt kein spezifisches Aggregatmodell, das von dieser Domäne abgeleitet werden kann, da es hauptsächlich hierarchisch ist.Sie haben im Grunde nur dumme Datenstrukturen innerhalb von Containern in anderen Containern. Keine Invarianten oder Geschäftsregeln in Sicht, keine Hinweise auf Teile, die unter gleichzeitigen Zugriffen stehen.

Wenn das alles an dieser Domain ist, würde ich nicht die DDD taktischen Muster verwenden, um es zu modellieren, es ist nur CRUD.

Wie der Titel des Buches geht, geht es bei DDD darum, Komplexität in Software, nicht unnötig auf einfache Probleme Ihre Haare herausziehen.