Wie wir komplexe Projekte mit Domain-Driven-Design in beherrschbare Teile schneiden

Nachdem Lena und ihr Team bei eine gemeinsame Sprache für das Projekt gefunden hatten (siehe „Die Macht der gemeinsamen Sprache“ ), stießen sie auf das nächste Problem: Das System war riesig. Es sollte die gesamte Lieferkette eines Online-Händlers abdecken – von der Bestellung bis zum Versand, von der Finanzbuchhaltung bis zum Retourenmanagement. Der Versuch, alles in einem einzigen, großen Softwaremodell abzubilden, war wie der Versuch, einen Elefanten auf einmal zu essen: unmöglich. Lena brauchte einen Weg, diesen „Elefanten“ in verdauliche Stücke zu zerlegen.

„Big Ball of Mud“

Viele große Softwaresysteme enden als „Big Ball of Mud“ – ein undurchsichtiges Gewirr, bei dem jede Änderung weitreichende und unvorhersehbare Konsequenzen hat. Das lag oft daran, dass alle Geschäftskonzepte in einem einzigen, großen Modell vermischt wurden. Ein „Produkt“ konnte für den Verkauf etwas anderes bedeuten als für das Lager, aber in der Software war es überall dasselbe, was zu Inkonsistenzen und Fehlern führte. Diese globale Komplexität, die durch viele Interaktionen und Abhängigkeiten entsteht, ist oft problematischer als die Komplexität einzelner Programmteile.

Bounded Contexts

Lena setzte auf einen weiteren strategischen Pfeiler des Domain-Driven Design (DDD): die Abgrenzung von Kontexten, oder „Bounded Contexts“. Die Idee ist einfach und genial: Man zerlegt das gesamte Geschäft des Online-Händlers in kleinere, eigenständige Geschäftsbereiche. Jeder dieser Bereiche erhält sein eigenes, in sich konsistentes Geschäftsmodell und eine darauf zugeschnittene, spezifische Sprache, die nur innerhalb seiner Grenzen gültig ist.

Stell dir vor: Anstatt eines einzigen, gigantischen „Produkt“-Modells, das alles von der Preisgestaltung bis zur Lagerung regelt, gab es nun:

• Einen „Verkaufs-Kontext„, in dem ein „Produkt“ Eigenschaften wie Preis, Rabatte und Marketingtexte hatte.
• Einen „Lagerhaltungs-Kontext„, in dem dasselbe „Produkt“ Attribute wie Standort im Lager, Größe und Gewicht besaß.
• Einen „Buchhaltungs-Kontext„, wo das „Produkt“ mit Umsatzsteuersätzen und Kostenstellen verbunden war.

Durch diese Abgrenzung konnte Lenas Team:

• Die Komplexität stark reduzieren: Jeder Kontext war klein genug, um vollständig verstanden und entwickelt zu werden.
• Die Konsistenz sicherstellen: Innerhalb eines Kontextes gab es keine widersprüchlichen Definitionen.
• Die Entwicklung beschleunigen: Unterschiedliche Teams konnten parallel an verschiedenen Kontexten arbeiten, ohne sich gegenseitig zu blockieren.
• Die Wartbarkeit verbessern: Änderungen in einem Kontext hatten weniger Auswirkungen auf andere.

Innerhalb dieser Bounded Contexts half DDD Lena auch dabei, die Prioritäten des Geschäfts klar zu definieren und Ressourcen optimal einzusetzen. Sie unterschieden drei Arten von Domänen (Geschäftsbereichen):

Core Domain

Dies ist das Herzstück des Geschäfts, der einzigartige Wettbewerbsvorteil des Online-Händlers. Hier wurde die meiste Energie, Kreativität und die besten Experten investiert, um innovative Lösungen zu entwickeln. Zum Beispiel die Optimierung der Lieferrouten oder personalisierte Empfehlungssysteme. Diese Domäne wurde detailliert modelliert, um ihre Einzigartigkeit voll abzubilden.

Generic Subdomain

Dies sind allgemeine Funktionen, die fast jedes Unternehmen benötigt und die keinen Wettbewerbsvorteil bieten. Beispiele hierfür sind die Benutzerverwaltung (Anmeldung, Passwort vergessen) oder ein einfaches E-Mail-Versandsystem. Hier konnte Lena auf bewährte Standardlösungen, fertige Bibliotheken oder Drittanbieterdienste zurückgreifen, anstatt das Rad neu zu erfinden.

Supporting Subdomain

Diese Domänen sind spezifisch für das Geschäft des Online-Händlers, aber nicht sein primärer Wettbewerbsvorteil. Zum Beispiel ein spezielles Reporting-Tool für interne Analysen. Hier wurde eine maßgeschneiderte Lösung entwickelt, aber mit weniger Investition als in der Kerndomäne.

Fazit

Durch diese Unterscheidung konnte das Team die wertvollen Ressourcen auf das Wesentliche konzentrieren und sicherstellen, dass die wichtigsten Geschäftsbereiche die höchste Aufmerksamkeit erhielten.

Die Zerlegung des Elefanten in abgegrenzte Kontexte und die Priorisierung der Domänen waren für das Projekt ein Game Changer. Es ermöglichte:

• Gezielte Investitionen: Ressourcen wurden dort eingesetzt, wo sie den größten Mehrwert für das Geschäft versprachen.
• Risikominimierung: Die Komplexität wurde in kleinere, überschaubare Einheiten aufgeteilt, was das Risiko von Fehlern in der Gesamtarchitektur reduzierte.
• Agilität: Einzelne Geschäftsbereiche konnten unabhängig voneinander weiterentwickelt und angepasst werden, was dem Online-Händler eine schnelle Reaktion auf Marktveränderungen ermöglichte.

Lenas Ansatz, das große Ganze in logisch abgegrenzte und priorisierte Geschäftsbereiche zu unterteilen, war entscheidend für den Erfolg des Projekts. Er bewies, dass es nicht darum geht, alles auf einmal zu verstehen, sondern darum, die richtigen Grenzen zu ziehen und sich auf das zu konzentrieren, was wirklich zählt – das Herzstück des Geschäfts.

Referenzen

• Vladik Khononov: Learning Domain-Driven Design
• Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software
• Vaughn Vernon: Implementing Domain-Driven Design