Wie hilft Domain-Driven Design beim Zuschnitt von Microservices?
Direkte Antwort
Domain-Driven Design liefert mit dem Konzept der Bounded Contexts eine fachliche Methode, um Microservice-Grenzen entlang tatsächlicher Geschäftsdomänen zu ziehen, statt sie zufällig an technischen Codestrukturen auszurichten. Ein Bounded Context markiert einen Bereich, in dem ein bestimmter fachlicher Begriff (etwa "Kunde") eine konsistente, in sich geschlossene Bedeutung hat — und wird zum natürlichen Kandidaten für einen eigenständigen Service.
"Ein Begriff wie "Kunde" bedeutet im Vertrieb etwas anderes als im Support — ein Bounded Context macht diese unterschiedliche Bedeutung explizit, statt sie in einem gemeinsamen Modell zu vermischen.
Die häufigste Ursache für falsch geschnittene Microservices ist nicht mangelndes technisches Können, sondern eine fehlende fachliche Analyse, bevor die technische Aufteilung beginnt.
Bounded Contexts als fachliche Grenzziehung
Domain-Driven Design geht davon aus, dass ein und derselbe fachliche Begriff in unterschiedlichen Teilen eines Unternehmens unterschiedliche Bedeutung und Attribute hat — ein Bounded Context grenzt den Bereich ab, in dem eine bestimmte Bedeutung konsistent gilt.
Diese fachliche Grenze wird zum natürlichen Kandidaten für eine Servicegrenze, weil innerhalb eines Bounded Context Änderungen meist zusammen erfolgen, während Änderungen über Bounded-Context-Grenzen hinweg seltener und expliziter koordiniert werden.
Context Mapping zwischen Bounded Contexts
Da reale Geschäftsprozesse oft mehrere Bounded Contexts durchqueren, definiert Domain-Driven Design zusätzlich Context-Mapping-Muster (etwa Anti-Corruption Layer oder Shared Kernel), die beschreiben, wie unterschiedliche Contexts kontrolliert miteinander kommunizieren, ohne ihre jeweilige interne Konsistenz zu verlieren.
Diese expliziten Schnittstellen zwischen Contexts werden in der technischen Umsetzung zu den API-Verträgen zwischen den entsprechenden Microservices.
Warum diese Analyse vor der technischen Umsetzung stehen muss
Ohne vorherige fachliche Domänenanalyse orientiert sich die Aufteilung oft an zufälligen technischen Strukturen (etwa "alles, was dieselbe Datenbanktabelle nutzt"), was zu Servicegrenzen führt, die fachlich nicht zusammengehören und ständige Cross-Service-Kommunikation für einfache fachliche Vorgänge erfordern.
Die Investition in Domain-Driven-Design-Workshops mit Fachexperten vor der technischen Zerlegung zahlt sich meist dadurch aus, dass die resultierenden Servicegrenzen stabiler bleiben, weil sie sich an tatsächlicher Geschäftslogik statt an aktueller Codestruktur orientieren.
Wann passt es — wann nicht?
Passt gut
- ✓Es gibt unterschiedliche fachliche Bedeutungen desselben Begriffs in verschiedenen Unternehmensbereichen
Passt nicht
- ✗Die Domäne ist klein und fachlich homogen ohne widersprüchliche Begriffsbedeutungen