Accidental Complexity in the Heart of Software

This blog post is also available in English

• DDD behandelt Domänenkomplexität als gegeben – bietet aber kein Werkzeug, um zu prüfen, ob diese Komplexität wirklich notwendig (essential) oder hausgemacht (accidental) ist.
• In Modernisierungsprojekten werden bestehende Prozesse mit DDD modelliert statt hinterfragt – die neue Architektur reproduziert die alte Dysfunktion mit moderner Technologie.
• Zeitdruck, fehlendes Mandat und strukturelles Eigeninteresse von Stakeholdern verhindern, dass Prozesse vereinfacht werden.
• Werkzeuge wie Domain Storytelling To-be existieren, werden in der Praxis aber kaum genutzt, weil der Projektkontext auf Umsetzung ausgerichtet ist, nicht auf Veränderung.
• Komplexität dient auch als Statussymbol: Sie signalisiert Expertise, schafft Arbeit – und wird deshalb selten aktiv reduziert.
• Die wichtigste Frage ist nicht, wie man etwas modelliert, sondern ob es überhaupt existieren muss.

In den letzten zehn Jahren konnten wir eine interessante Beobachtung machen: Es gab eine Welle von Digitalisierungs- und Modernisierungsprojekten. Ungefähr zur gleichen Zeit wurde Domain-Driven Design zum Mainstream. Taktische Patterns wie Aggregate oder Repository sowie strategische Patterns wie Context Maps oder Bounded Contexts sind heute allgegenwärtig – auch und gerade in diesen Modernisierungsprojekten.

Auf den ersten Blick ist das lediglich eine zeitliche Korrelation. Aber es gibt guten Grund anzunehmen, dass hinter dem gleichzeitigen Aufstieg von Modernisierungsprojekten und der wachsenden Popularität von DDD mehr als ein Zufall steckt. Genau das wollen wir in diesem Beitrag untersuchen.

„Alles, was sie tun kann, ist sie zu kontrollieren"

Die kanonische Quelle zu Domain-Driven Design ist Eric Evans' gleichnamiges Buch[1]. Martin Fowler schreibt im Vorwort, dass die Komplexität im Herzen eines Softwaresystems nicht vermieden werden kann – alles, was Software tun kann, ist sie zu kontrollieren. Evans selbst ist im Vorwort nicht weniger deutlich: Die größte Komplexität vieler Anwendungen liegt nicht in der Technologie, sondern in der Domäne selbst, und diese Komplexität muss bewältigt werden.

Kein einziges Pattern im Blue Book zielt darauf ab, Komplexität infrage zu stellen, geschweige denn sie zu eliminieren.

Essential oder Accidental?

1986 unterschied Fred Brooks in No Silver Bullet[2] zwischen Essential Complexity und Accidental Complexity. Essential Complexity steckt im Problem selbst – sie lässt sich nicht wegdiskutieren. Accidental Complexity ist gemacht: historisch gewachsen, durch Organisationsstrukturen geformt, von niemandem hinterfragt.

Evans geht im Blue Book davon aus, dass die Domänenkomplexität, der wir begegnen, tatsächlich essential ist. Sie wird als gegeben hingenommen. DDD bietet Werkzeuge, um sie handhabbar zu machen. Aggregates, Bounded Contexts, Anti-Corruption Layers, Domain Events – das sind alles Werkzeuge für genau diese Aufgabe. Kein einziges Pattern fragt, ob diese Komplexität tatsächlich existieren muss.

Ein erheblicher Teil dessen, was wir für Essential Complexity halten, ist in Wirklichkeit hausgemacht. Prozesse, die „schon immer so waren", werden nicht mehr als begründungsbedürftig wahrgenommen. Ihre bloße Existenz gilt als Beweis für ihre Notwendigkeit. Das ist kein DDD-Problem. Es lässt sich besser durch das psychologische Phänomen des Status-quo-Bias erklären, wie es Kahneman und Tversky beschrieben haben: Verluste wiegen psychologisch schwerer als gleichwertige Gewinne, und die Aufgabe des Status quo fühlt sich wie ein Verlust an.

DDD ist das richtige Werkzeug für Essential Complexity. Das Problem ist, dass die Methodik keine Antwort auf die Frage bietet, wie man erkennt, ob Komplexität wirklich essential ist. Und weil die Werkzeuge von DDD so gut darin sind, Komplexität handhabbar zu machen, lässt der Druck nach, der nötig wäre, um diese Frage überhaupt zu stellen. Es ist wie ein sehr wirksames Schmerzmittel: Sobald die Symptome gut behandelt sind, fragt niemand mehr nach der Ursache.

Was in der Praxis passiert

Aus meinen eigenen Beobachtungen in einer Vielzahl von Projekten kann ich sagen, dass der Einsatz taktischer DDD-Patterns zu einem unhinterfragten Modus Operandi geworden ist. Das ist nicht unbedingt falsch – sie sind eine nützliche gemeinsame Designsprache, mittlerweile fast eine Lingua franca. Aber es ist auch ein Symptom dafür, dass Komplexität zunehmend als Normalzustand akzeptiert wird.

Bei den strategischen Patterns wird es interessanter. Werkzeuge wie Bounded Contexts, Context Maps und Subdomains sind explizit dafür gedacht, die richtigen Schnitte zu finden. Evans und Vernon würden niemals sagen: Zeichne die bestehenden Abteilungsgrenzen nach und nenne das eine Context Map. Aber genau das passiert viel zu oft. Der Monolith wird zerlegt, die Bounded Contexts folgen Conway’s Law, und die neue Architektur spiegelt die alte Organisationsstruktur wider. Die Dysfunktion bekommt neue Kleider.

Das ist kein Fehlgebrauch, den man DDD anlasten kann. Aber es passiert systematisch, und die Erklärung liegt nicht in DDD selbst, sondern im Kontext, in dem es eingesetzt wird.

Das Ergebnis ist häufig, dass neue Software mit modernen Technologien gebaut wird, aber lediglich die alten Prozesse reproduziert. Häufig nicht einmal das – denn in der Legacy-Welt sind viele Prozesse gar nicht explizit in Software modelliert, sondern leben in den Köpfen der Menschen und in Excel-Tabellen.

Ein Symptom solcher Modernisierungsprojekte sind User Stories, die nur die gewünschten Auswirkungen auf die Benutzeroberfläche beschreiben, aber über den zugrundeliegenden Geschäftsprozess schweigen – ein Badge, das einen Status anzeigt, ein Button, der ihn speichert, und ein Business-Workflow, der weiterhin vollständig in den Köpfen der Mitarbeitenden stattfindet, außerhalb der teuer modernisierten Software.

Zu spät, zu viel Druck

Warum ist das so? Es gibt keine einfache Erklärung, aber nach meiner Erfahrung spielen mehrere Faktoren eine Rolle. Einer ist, dass Modernisierungsprojekte oft nicht dann starten, wenn es sinnvoll wäre, sondern wenn der Schmerz unerträglich wird. Das Legacy-System verursacht so viele Probleme, dass es so schnell wie möglich abgeschaltet werden muss. Genau dieser Druck ist der Grund, warum niemand mehr Zeit hat, Prozesse neu zu denken.

Reinertsen[3] hat Cost of Delay als Metrik im Kontext der Neuproduktentwicklung populär gemacht: Was kostet es uns pro Woche, die wir das Produkt später als geplant auf den Markt bringen? Das Konzept gilt aber ebenso für Legacy-Modernisierung. Wer früh modernisiert, hat noch Spielraum für Entscheidungen. Wer wartet, bis es brennt, modernisiert unter Notfallbedingungen – jede weitere Verzögerung bei der Ablösung des alten Systems ist extrem teuer.

Bestehende Prozesse mit DDD zu modellieren kostet Zeit. Aber es kostet weniger Zeit als echte Prozessreflexion und Veränderung, und vor allem erfordert es keinen organisatorischen Mut. Unter Druck gewinnt immer die Methodik, die beides spart.

Das fehlende Mandat

Auch ohne Zeitdruck: Auftraggeber bestellen typischerweise Software, keine Prozessberatung. IT-Architekt:innen haben ein Mandat für Technologie, nicht für die Fachdomäne. Alle machen ihren Job. Niemand macht den Job, der eigentlich nötig wäre.

Dass das Mandat so selten erteilt wird, hat Gründe, die über Zeitdruck und Rollendefinitionen hinausgehen. Prozessvereinfachung ist für einige Stakeholder schlicht existenzbedrohend. Diese Stakeholder und die zugehörigen Abteilungen haben ein strukturelles Interesse an der Existenz von Prozessen, die gesteuert werden müssen. Das ist keine Kritik; es ist rationales Eigeninteresse, geformt durch Organisationsstrukturen und Anreize. Aber es erklärt, warum die Frage nach Vereinfachung so selten gestellt wird.

Domain Storytelling to-be – das vernachlässigte Werkzeug

Das Werkzeug für den richtigen Schritt existiert übrigens. Hofer und Schwentner haben das To-be-Szenario in Domain Storytelling[4] als gleichberechtigten Modus eingebaut, nicht als Anhängsel. Es geht ausdrücklich nicht darum zu modellieren, wie die Dinge sind, sondern wie sie sein sollten.

In der Praxis ist es fast immer nur As-is oder ein halbherziges To-be, das sich nicht traut, nennenswert von bestehenden Prozessen und Strukturen abzuweichen – schlicht weil der Projektkontext auf Umsetzung ausgerichtet ist, nicht auf Prozessveränderung. Der Moment, in dem ein To-be, das wirklich etwas verändert, möglich wäre, ist oft bereits verstrichen, wenn das Projekt startet.

Komplexität als Statussymbol

Es gibt noch eine Dimension, die selten offen diskutiert wird. Manche praktizieren DDD nicht trotz der Komplexität, sondern gerade wegen der Komplexität. Komplexe Lösungen signalisieren Expertise. Das DDD-Vokabular signalisiert Zugehörigkeit zur Community. Wer Komplexität eliminiert, hat nichts vorzuweisen. Wer ein ausgefeiltes Domain Model präsentiert, demonstriert Können.

Das ist eine spezifische Ausprägung dessen, was Graeber in Bullshit Jobs[5] beschreibt: Menschen, die Sinn für sich selbst erzeugen, indem sie Komplexität managen, die sie selbst erzeugt haben. Für Berater:innen kommt ein struktureller Anreiz hinzu: Komplexität schafft Arbeit.

Die ernüchternde Bilanz

Die Welle von Digitalisierungs- und Modernisierungsprojekten der letzten zehn Jahre war real. Die Ergebnisse dieser Projekte sind ernüchternd. Das Haupthindernis ist meist nicht schlechte Technologie, sondern die mangelnde Veränderungsbereitschaft einer Organisation.

Das ist kein Zufall. Es ist die direkte Konsequenz davon, Modernisierung als technisches Problem zu behandeln. Neue Systeme, neue Architektur, sorgfältig modellierte Domänen – aber die Organisation bleibt, wie sie ist. Dann ist das Ergebnis vorhersehbar: Die Dysfunktion überlebt die Technologie.

Fazit

Modernisierungs- und Digitalisierungsprojekte sind keine Technologieprojekte. Sie erfordern eine Organisation, die bereit ist, sich zu verändern – und das ist mehr als neue Software einzuführen und Mitarbeitende in deren Nutzung zu schulen. Solange das nicht verstanden wird, solange Modernisierung als technisches Problem mit technischen Lösungen behandelt wird, wird sich strukturell nichts ändern. DDD bietet das perfekte Werkzeug für dieses Mindset, und niemand hat einen starken Anreiz, daran etwas zu ändern.

Was Entwickler:innen und Berater:innen tun könnten: beharrlich fragen. Warum muss das so sein? Warum nicht einfach das Legacy-System weiterlaufen lassen? Nicht als Rhetorik, sondern als echte Frage, immer wieder gestellt. Die wichtigste Frage ist nicht, wie man etwas modelliert, sondern ob es überhaupt existieren muss.

1. Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003  ↩︎

2. Fred Brooks: No Silver Bullet: Essence and Accidents of Software Engineering, 1986  ↩︎

3. Donald Reinertsen: The Principles of Product Development Flow, Cenna Books, 2009  ↩︎

4. Stefan Hofer, Henning Schwentner: Domain Storytelling, Addison-Wesley, 2021  ↩︎

5. David Graeber: Bullshit Jobs, Simon & Schuster, 2018  ↩︎