In der heutigen komplexen Welt der Softwareentwicklung ist die Herausforderung, komplexe Geschäftsprozesse richtig zu verstehen und effizient abzubilden, größer denn je. Häufig entstehen Systeme, die schwer wartbar sind, sich nur schlecht an neue Anforderungen anpassen lassen und zudem die eigentlichen Geschäftsprozesse nicht richtig widerspiegeln. Genau hier setzen zwei innovative und zugleich pragmatische Ansätze an: Event Storming und Domain-Driven Design (DDD). Diese Methoden bieten einen strukturierten, kollaborativen Weg, um Domänenwissen zu sammeln, zu modellieren und in Softwarelösungen zu überführen, die den realen Anforderungen gerecht werden. Maciej „MJ“ Jedrzejewski hat mit seinem Werk „Understand Your Domain First: An Introduction to Event Storming and Domain-Driven Design“ eine wertvolle Ressource geschaffen, die Einsteigern und erfahrenen Professionals gleichermaßen den Einstieg erleichtert und praxisnah Wissen vermittelt.
Event Storming ist eine Workshop-Methode, die ursprünglich von Alberto Brandolini entwickelt wurde, um komplexe Geschäftsprozesse schnell und visuell zu erfassen. Dabei kommen verschiedene Stakeholder zusammen – Entwickler, Fachbereichsexperten, Architekten und Produktmanager –, um gemeinsam alle wichtigen Ereignisse innerhalb einer Domäne zu identifizieren. Das Ziel ist ein gemeinsames Verständnis, das „Fachliches Modell“, das später als Basis für die Softwareentwicklung dient. Im Gegensatz zu klassischen Anforderungsworkshops liegt bei Event Storming der Schwerpunkt auf dem Prozess und den Ereignissen, die tatsächlich die Realität im Unternehmen widerspiegeln. Die Methode ist dadurch besonders agil, leicht zugänglich und bietet frühzeitiges Feedback.
Die Stärke von Event Storming zeigt sich vor allem darin, dass es die Kluft zwischen Fachbereich und Technik überbrückt. Oftmals scheitern Projekte daran, dass Entwickler die Geschäftsprozesse nur unzureichend verstehen oder Fachbereiche ihre Anforderungen nicht klar kommunizieren können. Durch die gemeinsame Arbeit an einem Ereignisstrom können Missverständnisse identifiziert und korrigiert werden, bevor sie sich zu teuren technischen Problemen entwickeln. Zudem fördert ein solches gemeinsames Modell das Vertrauen und die Zusammenarbeit im Team. Domain-Driven Design geht einen Schritt weiter und liefert das konzeptionelle Rahmenwerk, um das erarbeitete Domänenwissen systematisch in Softwarearchitekturen zu übersetzen.
Eric Evans, der Begründer von DDD, stellte die Idee in den frühen 2000er Jahren vor und konzentrierte sich darauf, Domänenlogik klar vom Rest der Anwendung zu trennen, sogenannte Bounded Contexts zu definieren und mittels eines einheitlichen Vokabulars zwischen allen Beteiligten zu kommunizieren. Im Kern geht es bei DDD um das tiefe Verständnis der komplexen Geschäftswelt und deren Abbildung in Software durch geeignete Modelle. Ein wichtiger Bestandteil des DDD-Ansatzes ist die Identifikation und Abgrenzung von Subdomänen. Eine Subdomäne repräsentiert einen abgegrenzten Teilbereich der Gesamtanwendung, der bestimmte Verantwortlichkeiten hat und in sich geschlossen betrachtet werden kann. Dadurch lassen sich große Herausforderungen in handhabbare Teile zerlegen, die unabhängig voneinander entwickelt und weiterentwickelt werden können.
Selbstständige Teams können so fokussierter arbeiten und die Wartbarkeit der Lösung steigt enorm. Darüber hinaus spielt das Konzept der Bounded Contexts eine fundamentale Rolle. Ein Bounded Context definiert den Gültigkeitsbereich eines bestimmten Modells und verhindert, dass Begriffe unterschiedlicher Geschäftsbereiche vermischt oder inkonsistent verwendet werden. So entsteht ein einheitliches Verständnis im jeweiligen Kontext, was die Kommunikation erleichtert und technische Überschneidungen verringert. Zwischen den einzelnen Bounded Contexts wird über klar definierte Schnittstellen und Integrationen kommuniziert.
Maciej Jedrzejewski legt großen Wert darauf, dass die Anwendung von Event Storming und DDD nicht bloß Theorie bleibt, sondern praxisorientiert vermittelt wird. Sein Werk richtet sich an Softwarearchitekten, Entwickler, Tech Leads und Produktmanager, die sich nicht nur für die reine Codierung interessieren, sondern die strategische Ebene und den Domänenhintergrund verstehen möchten. Durch seinen Workshop-ähnlichen Aufbau erlebt der Leser die Entwicklung eines Modells durch eine reale Fallstudie – das Beispiel eines Fitnessstudios – und kann die Methoden direkt nachvollziehen und adaptieren. Die Vorteile einer solchen Vorgehensweise sind vielfältig. Einerseits lassen sich Risiken bei neuen Projekten durch ein frühzeitiges, gemeinsames Verständnis reduzieren.
Wenn Anforderungen unklar sind oder ständig verändert werden, hilft die iterative Erarbeitung von Modellen dabei, schnell auf Veränderungen zu reagieren und Planungsfehler zu vermeiden. Andererseits erhöhen gut modellierte Domänen das Potenzial, Systeme zukunftsfähig zu gestalten, da sie leichter erweiterbar und wartbar sind. Ein weiterer positiver Aspekt ist die Förderung der teamübergreifenden Kommunikation. In Zeiten von verteilten Teams, schnellem Wandel und agilen Arbeitsmethoden ist es essenziell, alle Beteiligten auf eine gemeinsame Basis zu bringen. Die Methodik schafft dafür geeignete Rahmenbedingungen.
Auch auf technischer Ebene unterstützt DDD die Erstellung modularer und kohärenter Softwarearchitekturen. Die Software wird nicht einfach fragmentiert nach technischen Schichten oder Programmiersprachen, sondern nach funktionalen Zusammenhängen der Domäne strukturiert. Dieses Prinzip erleichtert die Umsetzung fortschrittlicher Architekturmuster wie Microservices, bei denen klare Grenzen und Verantwortlichkeiten entscheidend sind. Trotz der vielen Vorteile ist es wichtig, sich bewusst zu machen, dass sowohl Event Storming als auch DDD eine Änderung im Mindset erfordern. Es gilt, die Denkweise zu verschieben von einer reinen Code-orientierten Entwicklung hin zu einer domänengetriebenen Lösung.
Dabei steht der Dialog und das gemeinsame Verständnis im Vordergrund, nicht nur die technologische Machbarkeit. Ebenso sollte die Organisation bereit sein, neue Kollaborationsformen zu etablieren und entsprechende Zeiträume für Workshops und Reflektionen einzuplanen. Maciej Jedrzejewski empfiehlt besonders, frühzeitig und kontinuierlich Domänenwissen zu sammeln und zu validieren. Ein festes Dokument oder ein starres Konzept sind selten zielführend in schnelllebigen Umgebungen. Praxisnah und agil angewandt sind Event Storming und DDD jedoch hervorragende Instrumente, um Qualität und Nachhaltigkeit in Softwareprojekten erheblich zu steigern.
