© Rawpixel.com/Shutterstock.com
Strategic Design

Umfassend und ganzheitlich …


Domain-driven Design bietet uns mit dem sogenannten Strategischen Design eine Anleitung, wie eine Domain und damit der Problemraum fachlich erfasst und aufgeteilt werden kann. Diese Aufteilung lässt sich dann auf den Lösungsraum – die Software – übertragen. Die Fachbegriffe aus DDD, die dabei eine Rolle spielen, sind: Domain, Subdomain, Bounded Context und schließlich die Context Map für das Zusammenspiel der Bounded Contexts. In diesem Artikel werden wir diese Begriffe und unser Verständnis davon vorstellen.

Die Domain und ihre Aufteilung in Subdomains lassen sich am besten mit den vorhandenen und zukünftigen Anwendern des Systems erarbeiten. Wir fangen in der Regel damit an, uns zusammen mit den Anwendern und Fachexperten einen Überblick über die Domain zu verschaffen. Das kann in Workshops mit Event Storming oder mit Domain Storytelling gemacht werden. Zwei Methoden, die für Anwender und Entwickler gleichermaßen gut verständlich sind [1]. Ergebnis dieser Workshops ist ein Verständnis der Ubiquitous Language (dt.: allgegenwärtige Sprache), der Fachsprache der Anwender, und der Abläufe, der Geschäftsprozesse, in der Domain.

Gleichzeitig bilden sich im Workshop Ideen heraus, wie die Domain in Subdomains aufgeteilt werden kann. Eine Subdomain ist ein Teil der umfassenden Geschäftsdomäne des gesamten Unternehmens. Die meisten Geschäftsdomänen sind zu groß und zu komplex, um sie als Ganzes zu betrachten. Durch die Zerlegung in Subdomains wird die Modellierungs- und Entwicklungsarbeit für die Teams beherrschbar und lässt sich auf spezifische Aspekte einschränken. Die große Kunst dabei ist es, beherrschbare Subdomains zu identifizieren und gegebenenfalls Subdomains, die im Laufe des Lebens einer Software zu groß werden, auch zu einem späteren Zeitpunkt in weitere Subdomains zerlegen zu können. Gute Indizien für diese Zerlegung sind die folgenden [1]:

  • Fachbegriffe werden von den Fachexperten unterschiedlich verwendet, sodass Begriffe in der einen Subdomain andere Aspekte umfassen als in der anderen Subdomain. Die verschiedenen Subdomains haben also jeweils ihre eigene Ubiquitous Language, wobei sich einige Begriffe in den verschiedenen Subdomains wiederholen, aber jeweils andere Aspekte des Begriffs beschreiben (z. B. hat eine Rechnung für die Einkaufsabteilung eine andere Bedeutung als für die Verkaufsabteilung eines Unternehmens).

  • Im Unternehmen sind Fachabteilungen, wie Einkaufs- und Verkaufsabteilung, vorhanden, in denen Fachexperten für die jeweilige Teilaufgabe zusammengefasst sind. Diese Abteilungen bilden ein Ökosystem mit seiner eigenen Sprache und seinen eigenen Details der Abläufe. Das deutet darauf hin, dass es hier auch jeweils eigene Subdomains geben sollte.

  • Bei der Erarbeitung des Big Pictures, also eines umfassenden Blicks auf die Abläufe in der Domain mit allen möglichen Teilprozessen, werden Stellen erkennbar, wo Information im Prozess nur in eine Richtung weitergegeben wird. Diese Stellen eignen sich gut als Grenzen für Bounded Contexts.

Damit wir entscheiden können, welche Subdomains für ein Unternehmen welche Bedeutung haben, bietet DDD eine Kategorisierung von Subdomains an. Es gibt drei Arten von Subdomains:

  • Core Domain (Kerndomäne, zentrale Teildomäne): Die Core Domain ist die wichtigste Subdomain. Durch die Software, die für die Core Domain entwickelt wird, setzt sich das Unternehmen von seinen Konkurrenten ab. In die Core Domain müssen daher die meisten Investitionen fließen und die Ubiquitous Language muss am besten herausgearbeitet werden. Um die Core Domain gut zu modellieren, muss mit Engagement, Zusammenarbeit und Experimentierfreude ein tiefes Verständnis der Geschäftsdomäne erreicht werden.

  • Supporting Subdomain (unterstützende Teildomäne): Für eine Supporting Subdomain müssen das Modell und die Software individuell entwickelt werden, weil es dafür keine Standardlösung gibt. Da es sich nicht um die Core Domain handelt, kann man in Erwägung ziehen, hier per Outsourcing einen externen Dienstleister einzusetzen. Nichtsdestotrotz sind Supporting Subdomains wichtige Softwaremodelle, denn ohne sie kann die Core Domain keinen Erfolg haben.

  • Generic Subdomain (allgemeine Teildomäne): Lösungen für Generic Subdomains kann man in der Regel als Standardsoftware kaufen und sollte das auch tun (z. B. Buchhaltungssoftware). Eine große Investition in diesen Bereich lohnt sich nicht, weil man sich mit diesem Teil der Domain nicht von der Konkurrenz absetzen kann.

Die Arbeit an der Domain und den Subdomains ist die Vorbereitung darauf, dass wir vom Problemraum in den Lösungsraum übergehen können, wo uns die DDD-Konzepte Bounded Context und Context Map erwarten. Dieser Übergang verläuft nicht sequenziell, sondern iterativ, sodass man bei der Entwicklung neuer Software oder der Überarbeitung von vorhandenen Systemen in kurzen Zyklen zwischen Problem- und Lösungsraum hin und hergeht.

Bounded Context

Ein Bounded Context ist wörtlich übersetzt ein abgeschlossener oder begrenzter Kontext. Das heißt, dass innerhalb einer bestimmten Grenze das Domain Model, also die implementierte Ubiquitous Language, eine bestimmte Bedeutung haben und bestimmte Dinge tun soll. Alle Klassen des Domain Models sind innerhalb eines Bounded Context kontextspezifisch und nur innerhalb dieses Kontexts zu verstehen.

Das DDD-Konzept Bounded Context weist uns auf ein häufig zu beobachtendes Problem beim Softwaredesign hin: Softwareentwicklungsteams haben gelernt, dass sie vorhandene Klassen und Komponenten in ihrer Software wiederverwenden sollen. Das führt dazu, dass die ganze Software auf einem Domain Model aufbaut, das alle Fachbegriffe aus der ge...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang