Domain Driven Design (DDD) ist kein Selbstzweck. Es ist eine Methode, mit der wir gemeinsam mit Fachexpert:innen Modelle entwickeln, die schließlich zur Grundlage funktionierender Software werden. In einer aktuellen Live-Session zeigte Matthias Bohlen, wie man genau diesen Übergang gestaltet: vom Prozessmodell zu definierten Softwarekomponenten.

Ausgangspunkt: Das Prozessmodell

Im Zentrum stand ein typischer Businessprozess – das betriebliche Vorschlagswesen. Mitarbeiter:innen sollen Verbesserungsvorschläge machen, kategorisieren und einreichen können. Über Event Storming auf Prozessebene (Level 2) wurden in der vorigen Folge der Live-Stream-Serie Trigger, Abläufe und erwartete Ergebnisse modelliert – etwa das Event „Vorschlag eingereicht“.

Das Ziel der Session war nun, diesen Prozess mithilfe von Softwarebausteinen zu unterstützen.

Schritt 1: Vom Prozess zu Komponenten

In Design-Level Event Storming (Level 3) wird ein Prozessmodell in konkrete Softwareelemente überführt. Doch wie macht man aus einem „Systemzettel“ ein Stück Software?

Matthias' Antwort: Wir denken in verantwortlichen Objekten – sogenannten Aggregates. Diese repräsentieren die „magischen Stellen im System, an denen die Action passiert“.

Zum Beispiel:

  • „Füge Vorschlag hinzu“ → könnte durch ein Vorschlags-Objekt verarbeitet werden.
  • „Lege Kategorie an“ → ist Aufgabe des Kategorie-Objekts.
  • „Benachrichtige Management“ → wird vom E-Mailserver ausgeführt.

Diese Aggregates verarbeiten Commands und produzieren Events, ganz im Sinne einer Zustandsmaschine (State Machine).

Schritt 2: Zuständigkeiten klären

Ein zentraler Schritt war das Gruppieren nach Verantwortlichkeiten. Statt Prozesse chronologisch anzuordnen, wurden die beteiligten Objekte ins Zentrum gerückt:

  • Das Vorschlagsobjekt verarbeitet zwei Commands: Vorschlag hinzufügen & einreichen.
  • Das Kategorieobjekt legt Kategorien an und ordnet Vorschläge ein.
  • Der E-Mailserver sendet Benachrichtigungen.

Diese Ordnung macht deutlich: Wer tut was in unserem System?

Schritt 3: Butter bei die Fische – welche Daten?

Am Ende stellte sich die klassische Entwicklerfrage: „Was steht eigentlich in so einem Command, Read Model, und Event drin?“

Matthias zeigte am Beispiel von „Füge Vorschlag hinzu“, wie man diese Inhalte konkretisiert:

  • Titel des Vorschlags
  • Beschreibung / Vorteil fürs Business
  • Geschätzter Aufwand
  • Zeitrahmen
  • Konsequenzen bei Nichtumsetzung

Solche Datenbeschreibungen helfen Entwickler:innen später, sinnvolle Interfaces und Event-Formate zu gestalten. Gleichzeitig bieten sie eine hervorragende Gesprächsgrundlage mit dem Fachbereich.

Fazit: Design ist Verständigung

Matthias Bohlen zeigt, dass Softwaredesign im DDD-Kontext kein rein technischer Akt ist. Es geht um das bewusste Gestalten von Zuständigkeiten und das gemeinsame Verstehen, wie jede Komponente den Prozess unterstützen soll. Wer das beherrscht, schafft Systeme, die der Fachlichkeit treu bleiben – und dabei wartbar, verständlich und sinnvoll erweiterbar sind.

Tipp: Wer tiefer einsteigen möchte, sollte sich Event Storming Workshops gönnen, bis hinunter zu Level 3. Hier zeigt sich, wie aus Ideen echte Software entsteht.

, Domain-Driven Design