Wie wir mit Domain-Driven-Design Softwareprojekte zukunftsfähig machen

Nachdem Lena und ihr Team die Sprache des Geschäfts gelernt und das System in verständliche Geschäftsbereiche unterteilt hatten, stand die Frage im Raum: Wie sollte die gesamte Software des Projekts grundsätzlich aufgebaut sein, um flexibel, wartbar und leistungsfähig zu bleiben? Es ging um die Architektur – das Skelett, das die gesamte Software zusammenhält und ihre zukünftige Entwicklung maßgeblich beeinflusst. Lena setzte auf bewährte Architekturstile, um das System widerstandsfähig gegen den Zahn der Zeit zu machen.

Starre Software und „Lock-in“

Eine schlechte Softwarearchitektur kann ein Projekt lähmen. Wenn technische Details (wie die Datenbank oder die Benutzeroberfläche) zu eng mit der Geschäftslogik verknüpft sind, wird jede Änderung teuer und riskant. Man ist an bestimmte Technologien „gefesselt“ (technologischer Lock-in) und kann nicht flexibel auf neue Anforderungen oder technologische Entwicklungen reagieren.

Die Geschäftslogik ins Zentrum rücken

Lena wusste, dass die Architektur die Geschäftslogik schützen und von den technischen „Details“ entkoppeln musste. Sie entschied sich für einen Architekturstil, der als „Onion Architektur“ (auch „Ports and Adapters“, „Clean Architecture“ oder „Hexagonale Architecture“) bekannt ist.

Stellen Sie sich die Geschäftslogik als das Herzstück eines Hauses vor – den Wohnbereich. Die Heizung, die Elektrik, die Wasserleitungen (die Infrastruktur) sind zwar notwendig, aber sie sollten so gebaut sein, dass man sie warten oder austauschen kann, ohne gleich das ganze Haus abreißen zu müssen. Die Onion Architektur funktioniert ähnlich:

• Im Zentrum steht die reine Geschäftslogik (die Domäne). Sie weiß nichts über Datenbanken, Benutzeroberflächen oder externe Schnittstellen.
  
  
• Um dieses Zentrum herum gibt es „Ports“ (Schnittstellen), die definieren, wie die Geschäftslogik mit der Außenwelt interagieren möchte (z.B. „Daten speichern“, „Benutzer informieren“).
  
  
• „Adapter“ sind die Übersetzer. Sie verbinden die Ports mit den konkreten technischen Systemen – sei es eine Datenbank, eine Web-Oberfläche oder ein anderes System. Ändert sich beispielsweise die Datenbanktechnologie, muss nur der entsprechende Adapter angepasst werden, nicht die Geschäftslogik selbst.

Dieser Ansatz macht die Software extrem widerstandsfähig gegen technologische Änderungen. Die Geschäftslogik bleibt stabil und kann unabhängig von der Infrastruktur getestet und weiterentwickelt werden. Dies reduziert Kosten und Risiken bei der Wartung und Weiterentwicklung.

Den Monolithen in Microservices zerlegen

Für das riesige Projekt, das viele verschiedene Geschäftsbereiche umfasste, entschied sich Lena, die zuvor definierten abgegrenzten Kontexte (Bounded Contexts) als separate „Microservices“ zu implementieren.

• Statt einer riesigen, monolithischen Software, die alles konnte, gab es nun viele kleine, spezialisierte Dienste. Jeder Microservice war für einen bestimmten Geschäftsbereich (z.B. „Bestellverwaltung“, „Lagerhaltung“) verantwortlich.
  
  
• Diese Dienste waren unabhängig voneinander und konnten von separaten Teams entwickelt, getestet und eingesetzt werden. Wenn ein Problem auftrat oder eine neue Funktion hinzugefügt wurde, betraf dies nur den jeweiligen Dienst, nicht das gesamte System.
  
  
• Datenisolierung war ein Schlüsselprinzip: Jeder Microservice hatte seine eigene Datenbank oder seinen eigenen Datenbereich, um Kopplung zu vermeiden und Unabhängigkeit zu gewährleisten.

Microservices förderten die Agilität und Skalierbarkeit des Systems erheblich. Teams wurden eigenständiger, die Entwicklungsgeschwindigkeit erhöhte sich, und das System konnte besser auf Lastspitzen reagieren, indem nur die benötigten Dienste skaliert wurden.

Kommunikation durch Ereignisse

Um die Microservices miteinander kommunizieren zu lassen, setzte Lena auf eine Event-Driven Architecture.

• Statt dass Dienste sich direkt gegenseitig aufrufen und auf eine Antwort warten (was zu enger Kopplung führen würde), sendeten sie „Ereignisse“ (Domain Events) aus, wenn etwas Wichtiges passierte (z.B. „Bestellung aufgegeben“).
  
  
• Andere Dienste, die sich für dieses Ereignis interessierten, abonnierten es und reagierten darauf, ohne zu wissen, wer es ursprünglich gesendet hatte.
  
  

Diese Art der Kommunikation erhöhte die Reaktionsfähigkeit und Flexibilität des Gesamtsystems enorm. Es ermöglichte lose Kopplung zwischen Diensten, da sie nicht direkt voneinander abhängig waren. Neue Funktionen oder Dienste konnten einfach „angehängt“ werden, indem sie sich für relevante Ereignisse anmeldeten, ohne bestehende Systeme ändern zu müssen (architektonische Erweiterbarkeit).

Fazit

Lenas Entscheidungen für die Onion Architektur, Microservices und eine ereignisgesteuerte Kommunikation schufen ein modernes, widerstandsfähiges und zukunftsfähiges System.

• Technologische Unabhängigkeit: Das Projekt war nicht an eine bestimmte Technologie gefesselt.
  
  
• Schnelle Anpassung: Neue Geschäftsanforderungen konnten schnell und zielgerichtet umgesetzt werden.
  
  
• Hohe Verfügbarkeit: Ausfälle einzelner Dienste legten nicht das gesamte System lahm.
  
  

Mit dieser Architektur legte Lena den Grundstein dafür, dass das Projekt nicht nur heute funktionierte, sondern auch morgen und übermorgen den Anforderungen des Online-Händlers gerecht werden konnte. Sie schuf ein System, das so flexibel war wie das Geschäft selbst, und das durch seine klaren Strukturen Kontinuität und Innovation ermöglichte.

Referenzen

• Robert Martin: Clean Architecture: A Craftsman’s Guide to Software Structure and Design
• Gernot Starke: Effektive Softwarearchitekturen ein praktischer Leitfaden
• Mark Richards, Neal Ford: Fundamentals of Software Architecture
• Vladik Khononov: Learning Domain-Driven Design_ Aligning Software
• Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software
• Vaughn Vernon: Implementing Domain-Driven Design