Alle sind sich über das Prinzip einig: das Domäne modellieren, bevor die Architektur gezeichnet wird. In der Praxis hält es selten mehr als zwei Sprints durch, bevor das Team zu dem zurückkehrt, was es kennt.
Das ist kein Mangel an Disziplin. Es ist eine Verwechslung von Ebenen.
Das Domainmodell und die Zielarchitektur sind keine aufeinanderfolgenden Schritte derselben Übung. Es sind zwei grundlegend verschiedene Übungen — mit unterschiedlichen Werkzeugen, unterschiedlichen Teilnehmern und unterschiedlichen Zielen. Sie zu verwechseln garantiert, dass Ihre neue Architektur die Einschränkungen der alten reproduziert.
Problem Space und Solution Space — Mechanik, keine Philosophie
Die Unterscheidung ist nicht konzeptuell. Sie ist operativ.
Das Domainmodell gehört zum Problem Space: Es beschreibt, was Ihre Organisation tut, unabhängig von jedem System. Was sind die realen Geschäftsprozesse? Welche Regeln regeln diese Prozesse? Wer ist dafür verantwortlich? Diese Analyseebene kennt keine Datenbanktabellen, keine Microservices, keine Migrationsbeschränkungen. Sie kennt nur die operative Realität.
Die Zielarchitektur gehört zum Solution Space: Sie beschreibt, wie technische Systeme diese Realität bedienen werden. Welche Services, welche APIs, welche Muster (CQRS, Event Sourcing, Bounded Contexts) zur Implementierung der auf der vorherigen Ebene identifizierten Geschäftsregeln?
| Domainmodell | Zielarchitektur | |
|---|---|---|
| Frage | Was tut die Organisation wirklich? | Wie wird Technologie diese Realität bedienen? |
| Ebene | Problem Space | Solution Space |
| Teilnehmer | Domain-Experten, Product Owner | Architekten, Tech Leads |
| Werkzeuge | Event Storming, Context Mapping | C4-Diagramme, ADRs, Bounded Contexts |
| Einschränkung | Keine — absichtlich | Budget, bestehender Stack, Team |
| Output | Ubiquitous Language, Bounded Contexts | Service Map, Migrationsplan |
Die Reihenfolge ist nicht verhandelbar. Das Domainmodell muss der Zielarchitektur vorausgehen — nicht weil es elegant ist, sondern weil Ihre Bounded Contexts ohne es Ihr IT-Organigramm widerspiegeln, nicht Ihre Geschäftsrealität.
Was Teams stattdessen tun — und warum das rational ist
In der Praxis passiert folgendes in den meisten Modernisierungsprojekten.
Das Team beginnt mit einem Domain-Modeling-Workshop. Drei Tage Event Storming, Post-its überall, Energie im Raum. Dann startet der erste Delivery-Sprint. Das Backlog wächst. Stakeholder wollen Demos. Der CTO ist gefangen zwischen dem Delivery-Druck und der Schuld des unvollendeten Domain-Modelings.
Im dritten Sprint wird das Domainmodell still zu einer verkleideten Zielarchitektur. Bounded Contexts spiegeln die Module des bestehenden ERPs. Die Ubiquitous Language kontaminiert sich mit dem Legacy-Vokabular. Man beginnt zu hören “ja aber in unserem aktuellen System ist es so strukturiert” — und niemand hinterfragt dieses “so.”
Dieses Verhalten ist rational. Der CTO steht vor realen Einschränkungen: ein Team, das liefern muss, Manager, die Fortschritte sehen wollen, ein Budget, das keine sechs Monate theoretisches Modellieren abdeckt. Der Druck, sich an das Bestehende zu klammern, ist strukturell unvermeidlich.
Das Problem ist nicht der Wille. Es ist das Setup.
Die Symptome des Kurzschlusses
Wenn das Domain-Modeling kurzgeschlossen wurde, erscheinen die Anzeichen Monate später — oft nach dem Go-live.
Bounded Contexts spiegeln das Organigramm. Wenn Ihre Services genau Ihren aktuellen IT-Teams entsprechen, ist das verdächtig. Bounded Contexts sollten die Geschäftsrealität widerspiegeln, nicht bestehende Organisationsgrenzen.
Die Ubiquitous Language ist durch das Legacy kontaminiert. Entwickler und Domain-Experten sprechen über dasselbe Konzept mit unterschiedlichen Begriffen. Oder schlimmer: Sie verwenden denselben Begriff für verschiedene Konzepte. Das ist das Zeichen dafür, dass das Domain-Modeling an der Oberfläche geblieben ist.
Geschäftsregeln sind über den Code verstreut. Ohne formalisiertes Domainmodell landen Geschäftsregeln in technischen Schichten — SQL, Validierungen in Controllern, Bedingungen in Event Handlern. Unmöglich zu warten, unmöglich Domain-Experten zu erklären.
Die Migration reproduziert das Bestehende. Modul für Modul, Tabelle für Tabelle kopiert das neue System das alte mit einem neuen Stack. Neue Technologie, gleiche Einschränkungen.
Ich habe dieses Muster in Projekten von 1,5M€ gesehen, die pünktlich geliefert wurden und bei denen die Nutzer ab dem ersten Tag nach dem Go-live frustriert waren. Das war kein Delivery-Versagen. Es war ein Design-Versagen.
Wie man es im Kontakt mit Delivery überleben lässt
Domain-Modeling stirbt unter dem Delivery-Druck, weil es als Phase positioniert wird — mit einem Anfang, einem Ende und einer Übergabe. Das ist das falsche Modell.
Beide Horizonte zeitlich trennen. Das Domain-Modeling muss dem Delivery um mindestens vier bis sechs Wochen vorausgehen. Wenn der Event-Storming-Workshop gleichzeitig mit dem ersten Sprint beginnt, hat er keine Chance. Delivery-Druck konsumiert immer die Abstraktion.
Domain-Modeling vor Kontingenzen schützen. Jemand muss für die Integrität des Domainmodells während des gesamten Projekts verantwortlich sein — unabhängig vom Sprint-Druck. Diese Rolle gehört nicht dem Tech Lead, der tief in der Delivery steckt. Es ist typischerweise ein Architekt oder externer Berater, der nicht in der täglichen Ausführung gefangen ist.
Mit Domain-Experten validieren, nicht mit Entwicklern. Die Ubiquitous Language wird mit denen aufgebaut, die die Geschäftsprozesse leben, nicht mit denen, die sie codieren werden. Wenn Ihr Event Storming nur Entwickler im Raum hat, modellieren Sie Ihr Systemmodell, nicht Ihr Domainmodell.
Gegen echte Grenzfälle testen. Bevor Sie zur Zielarchitektur wechseln, das Domainmodell gegen Ihre komplexesten Situationen prüfen — Ausnahmen, Grenzfälle, Regeln, die widersprüchlich erscheinen. Dort erscheinen die Lücken, nicht in den Nominalflüssen.
Das “Warum” jedes Bounded Context dokumentieren. Jeder Bounded Context muss in einem Geschäftssatz erklärbar sein, ohne DDD-Jargon. Wenn Sie es einem Geschäftsführer nicht erklären können, haben Sie ein technisches Artefakt modelliert, kein Geschäftskonzept.
Also, konkret
Wenn Sie CTO eines laufenden Modernisierungsprojekts sind, eine direkte Frage: Wer in Ihrem Team ist heute für die Integrität des Domainmodells verantwortlich?
Wenn die Antwort “niemand” oder “alle” ist — löst sich das Domainmodell bereits in der Zielarchitektur auf.
Das Problem ist nicht, dass Ihr Team nicht weiß, wie man DDD macht. Es ist, dass das Setup das Domain-Modeling nicht vor dem Delivery-Druck schützt. Der Tech Lead, der Sprints beaufsichtigt, kann nicht gleichzeitig den analytischen Abstand aufrechterhalten, der notwendig ist, um den Problem Space intakt zu halten.
Genau dort hat externe Beteiligung Wert — nicht um das Team zu ersetzen, sondern um die Rolle zu übernehmen, die die interne Struktur nicht übernehmen kann: die Integrität des Domainmodells aufrechtzuerhalten, während Delivery voranschreitet.
Das ist das Erste, was ich in einem Architektur Assessment untersuche: Existiert das Domainmodell unabhängig vom aktuellen System, oder ist es bereits eine Projektion des Bestehenden.
Wenn Sie CEO statt CTO sind und ein Modernisierungsprojekt vorbereiten, dieser Artikel behandelt dieselbe Dynamik aus der Geschäftsperspektive →