In dieser Episode meldet sich Matthias Bohlen von zu Hause aus zurück, und knüpft an frühere Folgen zum Thema Domain-Driven Design an. Er beginnt mit einem Rückblick auf die Prozessmodellierung des betrieblichen Vorschlagswesens aus einer früheren Episode. Dort wurde bereits das Grundkonzept vorgestellt: Mitarbeiter können Vorschläge einbringen, die von der Geschäftsführung geprüft werden. Im vorherigen Video wurde gezeigt, wie die modellierten Systeme in Aggregates feiner zerteilt werden, und wie jedes Aggregate eine eindeutige Verantwortung bekommt.

Die Aufzeichnung der Sendung aus Zürich

Vom Event Storming zum Detailmodell

Matthias erläutert diesmal den Übergang vom gröberen Event-Storming-Modell zu einem detaillierteren Domain-Driven-Design-Modell. Er zeigt den grundlegenden Ablauf: Ein Command (blau) wirkt auf ein Aggregate (gelb), woraus ein Event (orange) resultiert. Diese Elemente müssen nun in feingranularere DDD-Bausteine wie Entities, Value Objects, Services und Repositories übersetzt werden.

Die DDD-Standardbausteine im Detail

Der Vortrag erklärt die wichtigsten DDD-Bausteine und ihre Funktionen:

  1. Value Objects: Commands wie "Füge Vorschlag hinzu" werden als Value Objects modelliert - unveränderliche Datenobjekte ohne eigene Identität, die nur ihren Wert repräsentieren.
  2. Aggregates: Ein Kernelement des DDD, bestehend aus Entities und Value Objects mit einer Root Entity und fachlichen Invarianten.
  3. Services: Bieten Zugriffspunkte für die Aggregate-Funktionalität und orchestrieren die Abläufe.
  4. Repositories: Verantwortlich für die Speicherung und das Wiederfinden von Aggregates anhand fachlicher Kriterien.
  5. Domain Events: Repräsentieren bedeutsame Ereignisse in der Domäne, wie "Vorschlag hinzugefügt".

Praktisches Beispiel: Vorschlagswesen

Matthias demonstriert anhand eines vorbereiteten Modells die konkrete Umsetzung des Use Cases "Füge Vorschlag hinzu". Er verwendet CRC-Karten (Class, Responsibility, Collaborators), um die beteiligten Objekte zu visualisieren:

  • Das Command-Objekt enthält Daten wie UserID, Vorschlagstitel, Businessvorteil, Umsetzungsaufwand und Zeitrahmen.
  • Der VorschlagService verarbeitet das Command und nutzt ein Repository.
  • Das VorschlagRepository bietet Methoden wie "addVorschlag" und "getVorschlagById".
  • Das Vorschlag-Aggregate enthält Attribute wie ID, EinreicherID, Zustand, Titel und BusinessVorteil sowie die Geschäftslogik.
  • Das Event-Objekt (VorschlagHinzugefügt) enthält Informationen wie Zeitstempel, UserID und VorschlagsID.

Der zweite Use Case: "Reiche Vorschlag ein"

Als zweites Beispiel erläutert Matthias den Use Case "Reiche Vorschlag ein". Hier wird demonstriert, wie ein kombinierter Lese-/Schreibvorgang modelliert wird:

  1. Das Command enthält nur die UserID und VorschlagsID
  2. Der Service lädt den Vorschlag aus dem Repository
  3. Die Businessmethode "reicheEin()" ändert den Zustand und erzeugt ein Event
  4. Das Event "VorschlagEingereicht" wird publiziert

Abschluss und Ausblick

Matthias fasst zusammen, dass der grundlegende Ablauf immer ähnlich ist: Ein Command wird vom Service verarbeitet, der auf die Business-Logik im Aggregate zugreift, wodurch Zustandsänderungen und Events erzeugt werden. Die technische Verteilung dieser Events (etwa über Kafka oder RabbitMQ) würde in einer späteren Folge behandelt werden. Als Ausblick auf die nächste Episode werden die restlichen DDD-Bausteine angekündigt, die noch nicht behandelt wurden.