Wie wir mit Domain-Driven-Design Software die Realität abbilden lassen

Nachdem Lena und ihr Team die gemeinsame Sprache etabliert und das Projekt in beherrschbare Geschäftsbereiche (Bounded Contexts) unterteilt hatten, stand die nächste Herausforderung an: Wie konnten die Entwickler:innen diese Geschäftskonzepte exakt und verständlich in der Software abbilden? Es ging darum, die „Dinge“ des Geschäfts – Kunden, Produkte, Bestellungen – nicht nur technisch zu speichern, sondern ihre Geschäftslogik und ihr Verhalten präzise in den Code zu bringen. Domain-Driven Design (DDD) bot hierfür eine Reihe von mächtigen Bausteinen.

Software als reine Datenverwaltung

Oftmals wird Software als reine „Datenbank-Verwaltung“ missverstanden. Man speichert einfach Daten in Tabellen und holt sie wieder heraus. Aber das Geschäft ist mehr als nur Daten: Es sind Regeln, Abläufe, Beziehungen und Zustände. Wenn diese Komplexität nicht direkt in der Software modelliert wird, landet sie irgendwo versteckt, oft in undurchsichtigen Datenbankprozeduren oder unstrukturiert im Code, was zu unlesbarer, schwer wartbarer Software führt.

Die Bausteine des Domain-Driven Designs

Lena führte ihr Team in die taktischen Muster (Building Blocks) von DDD ein, die dabei helfen, das Geschäftsmodell direkt in den Softwarecode zu übersetzen.

Entities

Lena erklärte, dass ein Kunde (Customer) eine „Entität“ ist. Ein Kunde ist immer derselbe, egal ob sich seine Adresse, Telefonnummer oder E-Mail-Adresse ändert. Er hat eine eindeutige Identität, die ihn über die Zeit hinweg erkennbar macht.

Das System kann die Kontinuität wichtiger Geschäftsobjekte gewährleisten, wie z.B. die Historie eines Kunden oder einer Bestellung, unabhängig von deren sich ändernden Details.

Value Objects

Im Gegensatz dazu ist eine Adresse (Address) ein „Wertobjekt“. Ändert sich nur ein Buchstabe in der Adresse, ist es eine neue Adresse. Wertobjekte werden durch die Zusammensetzung ihrer Werte identifiziert und sind unveränderlich.

Wertobjekte helfen, Konzepte wie Geldbeträge, Datumsbereiche oder Messwerte präzise und fehlerfrei zu modellieren, da sie nicht versehentlich verändert werden können. Sie fördern die Lesbarkeit des Codes, indem sie die Bedeutung von Werten klar machen.

Aggregates

Lena betonte, dass nicht jedes Objekt einzeln manipuliert werden sollte, um die Geschäftslogik intakt zu halten. Eine Bestellung (Order) und ihre Bestellpositionen (OrderItems) sind ein typisches Beispiel: Sie gehören untrennbar zusammen. Man kann eine Bestellposition nicht einfach löschen, ohne die Gesamtbestellung zu beeinflussen.

Solche Gruppen bilden ein „Aggregat“, wobei das Hauptobjekt (hier die „Bestellung“) die Aggregate Root ist. Zugriffe von außen sind nur über diese Wurzel erlaubt, um die Konsistenz und Integrität der gesamten Gruppe zu gewährleisten.

Aggregate schützen wichtige Geschäftsregeln. Sie stellen sicher, dass eine Bestellung niemals in einem ungültigen Zustand sein kann, weil immer die richtigen Regeln angewendet werden, wenn interne Teile geändert werden. Dies minimiert Fehler und sorgt für verlässliche Geschäftsabläufe.

Domain Services

Manche Aktionen, wie das „Überprüfen der Verfügbarkeit eines Produkts in allen Lagern“, passten nicht natürlich zu einem einzelnen Kunden, Produkt oder einer Bestellung. Dafür definierten sie „Domain Services“. Dies sind zustandslose Operationen, die domänenspezifische Logik kapseln und die Zusammenarbeit mehrerer Aggregate koordinieren.

Domain Services helfen, komplexe Geschäftslogik, die mehrere Objekte betrifft, klar zu strukturieren und wiederverwendbar zu machen, ohne die einzelnen Objekte zu überladen.

Domain Events

Wenn eine „Bestellung aufgegeben“ wurde, war das ein wichtiges Ereignis, das viele andere Geschäftsbereiche interessierte (z.B. Lager, Rechnungsstellung, Versand). Lena sorgte dafür, dass solche Geschäftsvorkommnisse als „Domain Events“ veröffentlicht wurden. Andere Systeme oder Kontexte konnten sich für diese Events interessieren und darauf reagieren, ohne direkt miteinander gekoppelt zu sein

Domain Events ermöglichen eine flexible und reaktionsschnelle Kommunikation zwischen Systemteilen. Wenn eine Bestellung aufgegeben wird, kann das Lagersystem automatisch die Artikel reservieren, während die Finanzabteilung die Rechnung vorbereitet, ohne dass die Systeme direkt voneinander wissen müssen. Das erhöht die Flexibilität und Skalierbarkeit des Gesamtsystems.

Fazit

Durch die konsequente Anwendung dieser DDD-Bausteine konnte Lenas Team Software entwickeln, die die Komplexität des Geschäfts genau abbildete und dabei robust und verständlich blieb.

• Verbesserte Code-Qualität: Der Code sprach die Sprache des Geschäfts, was die Lesbarkeit und Verständlichkeit enorm erhöhte.
  
  
• Geringere Fehlerrate: Geschäftsregeln wurden direkt im Code geschützt, was zu weniger Fehlern führte.
  
  
• Erhöhte Agilität: Änderungen an Geschäftsregeln konnten zielgerichteter umgesetzt werden, da ihre Verortung im Code klar war.

Mit den Bausteinen des Domain-Driven Designs verwandelte Lena die Software von einer bloßen Datenverwaltung in ein präzises digitales Abbild des Geschäfts. Dies ermöglichte es dem Projekt, die tatsächlichen Anforderungen des Online-Händlers zuverlässig und effizient umzusetzen und so einen echten Mehrwert zu schaffen.

Referenzen

• 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