Читать книгу Vom Monolithen zu Microservices - Sam Newman - Страница 33

Im DDD ist ein Aggregat ein etwas verwirrendes Konzept, für das es viele verschiedene Definitionen gibt. Handelt es sich einfach um eine beliebige Sammlung von Objekten? Die kleinste Einheit, die ich aus einer Datenbank holen sollte? Bei dem Modell, das bei mir immer funktioniert hat, ist ein Aggregat eine Repräsentation eines Konzepts aus der realen Domäne – stellen Sie sich so etwas vor wie eine Bestellung, eine Rechnung, ein Lagerteil oder Ähnliches. Aggregate haben normalerweise einen Lebenszyklus, der es ermöglicht, dass sie als Zustandsmaschine implementiert werden. Wir wollen Aggregate als in sich geschlossene Einheiten behandeln und sichergehen, dass der Code, der sich um die Zustandsübergänge eines Aggregats kümmert, mit dem Zustand selbst in einer Gruppe zusammenbleibt.

Denken wir über Aggregate und Microservices nach, kümmert sich ein einzelner Microservice um den Lebenszyklus und die Datenspeicherung eines oder mehrerer Typen von Aggregaten. Möchte die Funktionalität in einem anderen Service eines dieser Aggregate ändern, muss sie entweder direkt eine Änderung an diesem Aggregat anfordern oder das Aggregat selbst auf andere Dinge im System reagieren lassen, um seinen eigenen Zustandsübergang auszulösen – Beispiele dafür sehen Sie in Abbildung 1-17.

Entscheidend ist hier, zu verstehen, dass ein Aggregat es auch ablehnen kann, wenn ein Außenstehender einen Zustandsübergang anfordert. Sie werden Ihre Aggregate idealerweise so implementieren, dass illegale Zustandsübergänge nicht möglich sind.

Aggregate können Beziehungen zu anderen Aggregaten haben. In Abbildung 1-18 gibt es ein Customer-Aggregat, das mit einer oder mehreren Orders verbunden ist. Wir haben uns entschieden, Customer und Order als getrennte Aggregate zu modellieren, die von unterschiedlichen Services betreut werden könnten.

Es gibt viele Möglichkeiten, ein System in Aggregate aufzuteilen, wobei manche Entscheidungen sehr subjektiv sein können. So kann es aus Performancegründen oder zur leichteren Implementierung angebracht sein, Aggregate nach einiger Zeit neu zu formen. Zu Beginn schlage ich aber vor, Implementierungsüberlegungen nachrangig zu betrachten und das Gedankenmodell der Systemanwender als die Richtschnur für das erste Design anzunehmen, bis andere Faktoren ins Spiel kommen. In Kapitel 2 werde ich Event Storming als gemeinschaftliche Übung vorstellen, die dabei hilft, diese Domänenmodelle mit der Hilfe von Kollegen zu bilden, die gerade keine Entwickler sind.

Abbildung 1-17: Verschiedene Möglichkeiten, wie unser Payment-Service einen »Paid«-Übergang in unserem Invoice-Aggregat auslösen kann

Abbildung 1-18: Ein Customer-Aggregat kann mit null oder mehr Order-Aggregaten verbunden sein.