Domain-Driven Design (DDD) ist der De-facto-Standard für die Dekomposition von Softwaresystemen und die Modellierung von komplexen Domänen. Der aufkommende Trend von Documentation as Code brachte zudem die Herausforderung, Domänenmodelle via Text abzubilden. Hier bietet das Open Source-Tool „Context Mapper“ eine Vielzahl intuitiver Funktionalitäten zur Unterstützung des Architekturprozesses.
Für den ersten Entwurf eines Domänenmodells wird meist auf Pen & Paper oder das Whiteboard zurückgegriffen. Darauf basierend werden Diskussionen mit Domänenexperten und Softwareingenieuren abgehalten, um ein gemeinsames Verständnis der Domäne zu erlangen. Die aus den Diskussionen entstandenen Zeichnungen werden fotografiert, abgelegt und sind innerhalb kürzester Zeit veraltet. Um dieses Problem zu beheben, wurde das Open Source-Tool Context Mapper im Jahr 2018 an der Ostschweizer Fachhochschule (OST) unter der Führung von Stefan Kapferer und Prof. Dr. Olaf Zimmermann entwickelt.
Context Mapper ist ein Framework für die Anwendung verschiedener DDD-Praktiken (unter anderem nach Eric Evans). Im Zentrum des Frameworks steht eine eigens definierte Domain-specific language (DSL), auch CML genannt. Diese ermöglicht sowohl die Definition als auch das Refactoring von komplexen Domänenmodellen unter der Verwendung der aus DDD bekannten Elemente wie Aggregate, Entitäten und Value Objects. Schlussendlich generiert Context Mapper aus der DSL ein passendes Klassendiagramm. Dieses basiert auf der darunterliegenden Logik vom Context Mapper – so werden zum Beispiel Relationstypen automatisch gesetzt.
Als einfaches Beispiel stellen wir uns die Domäne einer Bibliothek vor. Ein mittels Pen & Paper erstelltes, triviales Domänenmodell könnte beispielsweise so aussehen:
Das im Zentrum stehende Aggregat ist der Leihschein. Dieser enthält die Information, welche Bücher aktuell von den Kund*innen der Bibliothek ausgeliehen wurden. Zusatzinformationen wie das jeweilige Ausleih- und Rückgabedatum werden dabei in einem separaten Value Object abgelegt.
Ein von der Bibliothek bereitgestelltes Buch wird als dedizierte Entität dargestellt und beinhaltet Informationen wie ISBN, Autor und Anzahl Seiten in Form eigener Value Objects.
Personen, welche eines oder mehrere Bücher ausleihen, werden mithilfe des Aggregats Kunde abgebildet. Die weitere Ausarbeitung dieses Aggregats wurde aus Gründen der Einfachheit vernachlässigt.
Die ursprüngliche Pen & Paper-Variante des Domänenmodells lässt sich nun in äquivalente DSL-Anweisungen übertragen:
Aus der via DSL erfassten Definition des Domänenmodells lässt sich nun direkt ein Klassendiagramm generieren. Context Mapper bietet hierzu verschiedene Exportformate an – unter anderem direkt als Bild (PNG, SVG), aber auch als PlantUML-Datei. Für den Fall unserer Bibliotheksdomäne generiert Context Mapper das folgende Diagramm:
Context Mapper generiert automatisch die folgenden Elemente:
- Definierte Domänenobjekte inkl. Beschriftung und farblicher Kennzeichnung
(A = Aggregat Root, E = Entität, V = Value Object) - Definierte Attribute / Properties (Name, Typ) pro Domänenobjekt
(z.B. buecher, kunde, ausleihInformationen für den Aggregate Root Leihschein) - Darstellung der Beziehungen zwischen den Domänenobjekten
- (Gerichtete) Assoziation für eine 1:1-Beziehung
- Komposition für eine 1:n-Beziehung zwischen Entität und Value Object oder zwischen Entität und Aggregate Root
- Aggregation für eine 1:n-Beziehung zwischen unabhängigen Entitäten
Da das Domänenmodell nun im Textformat definiert ist, kann mittels eines Versionskontrollsystems wie Git einfach überprüft werden, wer wann welche Änderungen vorgenommen hat. Zusätzlich kann der Definition of Done ein Punkt hinzugefügt werden, dass die Domänenmodelle entsprechend nachgeführt werden müssen. So wird DDD ein Teil des Entwicklungs- und Reviewprozesses – und nicht ein Teil der nächsten Altpapiersammlung.
