Rollenbasierter Modellierung für das Domain-driven Design

Dieser Blogpost ist meine Proseminararbeit mit dem Titel „Nutzbarkeit von Rollenbasierter Modellierung im Domain-driven Design“ aus dem Sommersemester 2020. Während das KIT noch einiges an der Vergabe der Proseminare verbessern sollte, habe ich im Nachhinein viel über wissenschaftliches Schreiben und Software-Entwurf gelernt. (Trotz kompliziertem und intransparentem Vergabesystem ist es letztendlich gefühlter Zufall, ob und welches Thema man bekommt.) Es gab ein Peer-Review durch zwei andere Teilnehmende des Seminars, allerdings lagen die Themengebiete sehr weit auseinander. Die nicht optimale Formatierung dieses Blogposts liegt daran, dass ich die Quelldateien in zwei Schritten mit pandoc umgewandelt habe.

Abstract #

Domain-driven Design (DDD) ist eine etablierte Methode zur Modellierung komplexer Softwaresysteme, zum Beispiel von Microservice-Architekturen. Obwohl DDD weite Verbreitung gefunden hat, fehlt es an einer soliden formalen Grundlage, die eine Validierung und Konsistenthaltung von Entwürfen ermöglichen würde. Im Gegensatz zu DDD stammt die rollenbasierte Modellierung aus der Forschung und hatte auch Einfluss auf die Entstehung von DDD. Die rollenbasierte Modellierung wird schon lange erforscht und besitzt mit dem Compartment Role Object Model (CROM) eine formale Modellierungssprache. Diese Arbeit untersucht die Übertragbarkeit von Konzepten des DDD auf die moderne rollenbasierte Modellierung. Eine Übertragbarkeit erlaubt zum einen die Verwendung von CROM als eine aussagekräftigere Modellierungssprache, verglichen mit der häufig verwendeten Unified Modeling Language (UML). Es werden zwei Forschungsfelder verknüpft und DDD stärker formalisiert. Bestehende Ansätze der Formalisierung verwenden UML und bieten keine ausreichende Übersicht über geteilte Modelle zwischen Bounded Contexts. In dieser Arbeit wird eine Abbildung von DDD-Konzepten in die CROM-Sprache beschrieben. Ziel ist es, eine Abbildung zu haben, mit der möglichst alle Konzepte des DDD bedeutungstreu abbildbar sind. Außerdem soll die Abbildung, im Gegensatz zu Darstellungen in UML, Einblick über Art und Inhalt des Austauschs zwischen mehreren Bounded Contexts geben. In einer Fallstudie wird die Vollständigkeit der gefundenen Abbildung illustriert. Außerdem werden in der Fallstudie Hinweise auf Konsistenz und Vollständigkeit der Abbildung gesammelt.

Motivation

DDD wurde 2004 von Eric Evans in seinem Buch Domain-driven design: tackling complexity in the heart of software (Evans 2004) beschrieben. Seither hat DDD große Verbreitung gefunden und ist auch heute noch aktuell, insbesondere im Kontext von Microservice-Architekturen. DDD ist eine Methode zum Entwurf komplexer Softwaresysteme. Durch Aufteilen des Gesamtsystems an Domänengrenzen und die Verwendung von Terminologie aus der Problemdomäne, werden Entwürfe leichter nachzuvollziehen. Evans (Evans 2004) verwendet eine Vielzahl von Strukturdiagrammen, um Modellierungsprozesse zu illustrieren. Diese Diagramme, einige davon an UML-Diagramme angelehnt, sind jedoch informeller Natur. Durch Beispielmodellierungen werden Konzepte eingeführt und teilweise mit Evans Erfahrungswissen begründet. Während diese Aufmachung des Buches sicherlich zur allgemeinen Verständlichkeit beiträgt, geht sie auf Kosten einer formalen Grundlage für DDD, die bis heute fehlt. In der Praxis werden unterschiedlichste Darstellungsformen verwendet, die versuchen DDD-Konzepte in einem Softwareentwurf darzustellen. Die Abwesenheit einer formalen Modellierungssprache hat mehrere Nachteile: Es kann keine Verifizierung von Entwürfen stattfinden, es besteht die Gefahr von Architekturdrifts und die verwendete informelle Mo­del­lier­ungs­spra­che muss manuell konsistent gehalten werden, um zu gewährleisten, dass alle Beteiligten die gleiche Interpretation einer gewählten Darstellung haben. DDD wurde durch verschiedene Methoden der Softwareentwicklung beeinflusst, unter anderen auch von der rollenbasierten Modellierung. Evans zitiert in (Evans 2004) ein Buch über rollenbasierte Modellierung (Wirfs-Brock and McKean 2003) und verwendet in seinen Beispielen Rollen, allerdings nur informell, ohne genauer auf deren Eigenschaften einzugehen. Dargestellt werden die Rollen in UML-Notation, die unzureichend ist, um wesentliche Eigenschaften von Rollen darzustellen (Steimann 2000).

Zur großen Popularität von DDD haben sicherlich mehrere Faktoren beigetragen. Einer davon dürfte der Ansatz von Evans sein, nicht nur technische Lösungen für domänenspezifische Probleme zu beschreiben, sondern die Brücke von der menschlichen und organisatorischen Ebene über den strategischen Entwurf bis hin zum taktischen Entwurf zu schlagen. Dabei beschreibt er wie verschiedene Akteur:innen, Do­män­en­ex­pert:in­nen, Soft­ware­ar­chi­tekt:in­nen und Entwickler:innen, zusammenarbeiten können, um komplexe Probleme softwaretechnisch zu lösen. Es wird nicht versucht durch den Einsatz von fortgeschrittenen Technologien Komplexität zu behandeln, stattdessen werden Prozesse beschrieben, um Domänen unabhängig von konkreten Technologien zu modellieren. Dabei werden Modelle in Kollaboration mit Domänenexpert:innen erstellt und eine gemeinsame Sprache, die ubiquitäre Sprache, entwickelt.

Zusätzlich zur erwähnten Abwesenheit einer formalen Modellierungssprache, ergeben sich weitere Probleme bei der Modellierung mit DDD. Durch das Aufteilen eines Systems in mehrere Bounded Contexts, werden für Entitäten absichtlich verschiedene Modelle entwickelt. Dies dient der Komplexitätsreduktion. Es ist bei einem DDD-Modell mit mehreren Bounded Contexts nicht mehr ersichtlich bei welchen Entitäten es sich um dieselbe Entität handelt. Diese Zusammenhänge werden durch die hier vorgeschlagene Abbildung ersichtlich.

DDD ist nicht statisch, sondern wurde immer wieder erweitert und mit anderen Methoden vereinigt. Beispiele dafür sind die Verbindung von DDD mit CQRS (Hakin 2010) oder die Verbindung von DDD und NoSQL (Bugiotti et al. 2014).

Rollenbasierte Modellierung wurde erstmals 1977 vorgeschlagen (Bachman and Daya 1977) und wird seitdem erforscht. Insbesondere ist rollenbasierte Modellierung gut dafür geeignet, Zusammenhänge zwischen Entitäten und deren Verhalten in verschiedenen Kontexten zu beschreiben. Dieser Aspekt von rollenbasierter Modellierung kann dazu beitragen, Entitäten in unterschiedlichen Bounded Contexts unterschiedlich zu modellieren, ohne den Zusammenhang zwischen den Modellen zu verlieren (Schön et al. 2019).

Steimann (Steimann and Stolz 2011) erklärt, dass viele als Entitäten (im Sinne der klassischen Objektorientierung) modellierte Objekte, besser als Rollen zu modellieren wären, da ihre Identitäten von anderen Entitäten abgeleitet ist und sie deshalb konzeptionell nicht rigide sind, was eine wichtige Metaeigenschaft von Entitäten ist. Diese Objekte können sinnvoller als Rollen modelliert werden. Somit werden Modelle aussagekräftigerer, was dem besseren Verständnis dient. In der Kommunikation mit Domänenexpert:innen können dadurch mehr Aspekte und Konzepte in das Domänenmodell übertragen werden. Die rollenbasierte Modellierung besitzt mit CROM eine formale Modellierungssprache (Kühn et al. 2015). Eine Abbildung von Konzepten des DDD auf die rollenbasierte Modellierung stellt eine formale Modellierungssprache für DDD bereit und erlaubt es mehr Zusammenhänge zwischen Entitäten in einer Modellierung zu repräsentieren.

Ziel dieser Arbeit ist die Beschreibung einer solchen Abbildung von DDD nach CROM. Dafür werden in die wichtigsten Begriffe und Grundlagen von DDD erklärt. In wird aktuelle Forschung zur Darstellung von DDD-Modellierungen durch formale Modellierungssprachen genannt und diskutiert. beschreibt konzeptionell mögliche zusammengehörige Urbilder und Bilder der Abbildung. In wird diese Abbildung konkret für CROM als Bildmenge beschrieben. Durch eine Fallstudie in wird die Zweckmäßigkeit der gefundenen Abbildung exemplarisch geprüft. Zuletzt werden in die Ergebnisse der Arbeit zusammengefasst und Ansatzpunkte für zukünftige Forschung genannt.

Einführung in Domain-driven Design und Rollenbasierte Modellierung

Domain-driven Design

Domain-driven Design (DDD) ist eine Methode zur Modellierung, Entwicklung und Weiterentwicklung von komplexen Softwaresystemen, die die Modellierung der zu realisierenden Fachdomäne in den Vordergrund rückt. Dabei werden in Zusammenarbeit mit Domänenexpert:innen Modelle entwickelt, die jeweils einen bestimmten abgegrenzten Bereich, den Bounded Context, beschreiben. Es wird nicht versucht, ein einheitliches Modell für das gesamte System zu erstellen. Dies dient dazu, Komplexität zu reduzieren und Mehrdeutigkeiten von Konzepten in unterschiedlichen Bereichen Rechnung zu tragen.

In dieser Arbeit wird, wie auch in (Evans 2004), die Modellierung eines Frachtgütersystems als laufendes Beispiel dienen. Hier sind Zulieferung, Kund:in und Bezahldienst verschiedene Bounded Contexts. Die Zulieferung benötigt mit Gewicht, Maßen, Gefahrgutklassifizierung, usw. andere Daten von einer Fracht, als eine Kund:in. Für diese ist nur eine Tracking-Id von Interesse, mit der sie den aktuellen Status ihrer Lieferung einsehen kann. Jeder Bounded Context hat seine eigene ubiquitäre Sprache, die verwendete Begriffe innerhalb klar definiert. Ein Konto kann im Bounded Context Nutzer:in ein Nutzer:innenkonto mit Name und Passwort sein, im Bereich des Bezahldiensts hingegen ein Bankkonto.

Die ubiquitäre Sprache erleichtern die Kommunikation mit den Domänenexpert:innen und sie wird durchgehend in Kommunikation, Quelltext und Dokumentation verwendet. DDD lässt sich in zwei Ebenen unterteilen — den strategischen Entwurf und den taktischen Entwurf. Der strategische Entwurf umfasst die Interaktion verschiedener Bounded Contexts, übergeordnete Architekturentscheidungen und die Zusammenarbeit von Entwickler:innenteams. Der taktische Entwurf umfasst den inneren Aufbau eines Bounded Contexts auf objektorientierter Ebene. Wobei DDD nicht nur auf objektorientierte Sprachen beschränkt ist, sondern auch in anderen Paradigmen einsetzbar ist (Wlaschin 2018). Diese Arbeit orientiert sich am ursprünglichen in (Evans 2004) beschriebenen objektorientierten Ansatz.

Nachfolgend werden die Begriffe und Muster des taktischen Entwurfs beschrieben. Die wohl wichtigste Unterscheidung ist die, zwischen Entitäten und Datenobjekten. Entitäten besitzen eine feste Identität und behalten diese über ihre gesamte Lebenszeit. Zum Beispiel ein Frachtcontainer. Dieser wird über eine weltweit eindeutige Containernummer (ISO 6346) identifiziert und bleibt genau derselbe Container von der Produktion bis zur Verschrottung. Die Farbe des Containers kann sich jedoch über seine Lebenszeit ändern, sowie auch andere Container die gleiche Farbe haben. Farbe ist daher ein Datenobjekt. Datenobjekte haben keine eigene Identität, sondern werden über die Gesamtheit ihrer Attribute identifiziert. Sie sind zudem unveränderlich. Wird zum Beispiel der Container von rot nach blau umlackiert, wird ein neues Farbobjekt verwendet, statt die Werte des vorherigen zu ändern. Datenobjekte können also immer neu erstellt werden.

Ein weiteres wichtiges DDD-Konzept ist das Aggregat. Es vereint Objekte, die zu jeder Zeit konsistent gehalten werden müssen. Von außen wird auf Aggregate über ein Wurzelobjekt zugegriffen, statt auf die interne Struktur zu referenzieren. Das Wurzelobjekt eines Aggregats muss eine Entität sein, um auf das Aggregat referenzieren zu können. Um Aggregate oder andere komplexe Objekte und Objektstrukturen erstellen zu können, gibt es Fabriken. Sie zentralisieren die Erstellung, ohne dies zur Aufgabe der zu erstellenden Objekte zu machen. Das Aggregat ist an das Entwurfsmuster Kompositum (Gamma et al. 1994) angelehnt, aber nicht äquivalent dazu. Fabriken hingegen werden durch klassische Entwurfsmuster wie Erbauer, Abstrakte Fabrik oder Fabrik-Methode (Gamma et al. 1994) implementiert, DDD beschreibt hier zusätzlich, in welchen Situationen Fabriken eingesetzt werden. Ähnlich zu Fabriken sind die Dienste. Sie zentralisieren Aufgaben, die aus Modellierungssicht nicht Aufgabe einer einzelnen Klasse sein können. Fabriken und Dienste sind zustandslos. Die einzige Ausnahme sind Fabriken für Entitäten, welche, je nach Implementierung, eindeutige Identifizierungen generieren müssen. Depots (englisch Repositories) dienen dazu, komplexe Abfragen zu kapseln und somit Austauschbarkeit von Implementierungen zu erleichtern. Komplexe Abfragen werden also an einer zentralen Schnittstelle definiert, statt sie bei den Klienten zu verteilen.

Im strategischen Entwurf steht die Interaktion von Bounded Contexts im Vordergrund. Bounded Context wird in (Evans 2004) initial nur durch die ubiquitäre Sprache definiert. Ein Bounded Context ist ein Teil des Gesamtsystems, in dem Begriffe der ubiquitären Sprache die gleiche Bedeutung haben. Später in dieser Arbeit wird diese Definition konkretisiert. Bounded Contexts beinhalten verschiedene Konzepte. Solche, die in der aktuellen Iteration des Systems, nur innerhalb eines Bounded Context existieren und nicht nach außen gegeben werden. Beispielsweise die Zahlungsinformationen, welche im Bezahldienst gespeichert werden, sind für keinen anderen Bounded Context von Interesse. Und auch solche, die, wie im Beispiel oben die Fracht, zwischen mehreren Bounded Contexts geteilt werden. Für die Umsetzung von geteilten Konzepten, über Implementierungsdetails hinaus, gibt es mehrere Muster im DDD. Diese werden Integrationsmuster genannt und verbinden organisatorische und technische Aspekte. Bounded Contexts bieten eine natürliche Grenze für die Zuständigkeiten unterschiedlicher Entwickler:innenteams. Für Integrationsmuster sind die Begriffe Upstream-Team und Downstream-Team zentral. Das Downstream-Team ist vom Upstream-Team abhängig, da es zum Beispiel funktionierende APIs des Upstream-Teams benötigt.

Beim Integrationsmuster Partnerschaft arbeiten die Teams mehrerer Bounded Contexts zusammen und passen Modelle nach ihren aktuellen Bedürfnissen an. Dieses Vorgehen bedarf viel Kommunikation und verhindert schnelle Entwicklung bei großen Bounded Contexts.

Das Integrationsmuster geteilter Kern beschränkt die Partnerschaft auf möglichst wenige klar definierte Teile des Modells, um den durch die Partnerschaft entstehenden Mehraufwand so gering wie möglich zu halten. Oftmals liegt eine Upstream-Downstream-Beziehung zwischen zwei Bounded Contexts vor. Damit das Upstream-Team die vom Downstream-Team benötigten Funktionalitäten implementieren kann, setzt das Kunde-Lieferant-Integrationsmuster das Downstream-Team in die Rolle eines Kunden, welcher Kundenwünsche, zum Beispiel in Form von Backlogitems, anmelden kann. DDD klassifiziert außerdem Bounded Contexts in Kerndomäne und weitere Teile des Systems (tatsächlich ist die Aufteilung deutlich feingranularer). Die Kerndomäne enthält das meiste Domänenwissen und ist essenziell für das System. Wenn ein weniger wichtiger Teil des Systems auf Dienste der Kerndomäne zugreifen will, dann wird er in vielen Fällen zum Konformisten. Ein Konformist kann die Entwicklung des Upstream-Teams nicht beeinflussen. Er verwendet die Schnittstellen, die er vom Upstream-Team bekommt. Dieses Integrationsmuster schafft Stabilität in den verwendeten APIs und hilft den Teams der Kerndomäne sich nicht auf Anforderungen von zu vielen Seiten konzentrieren zu müssen. Ein weiterer Anwendungsfall für das Konformisten-Integrationsmuster ist die Interaktion mit Altsystemen. Diese lassen sich in vielen Fällen nicht auf aktuelle Bedürfnisse anpassen. Um veraltete Entwurfsentscheidungen nicht in neue Entwürfe einfließen zu lassen, gibt es das Integrationsmuster Antikorruptionsschicht. Dabei wird ähnlich zum Adaptermuster aus (Gamma et al. 1994) die Schnittstelle eines Systems transformiert, um in den Entwurf eines anderen Systems zu passen. Zuletzt soll noch der Vollständigkeit halber das Integrationsmuster getrennte Wege genannt werden. Hier haben sich die Teams dazu entschieden, keine Funktionalität des anderen Teams zu verwenden, beispielsweise weil eine Zusammenarbeit in der Abwägung gegen etwas duplizierte Funktionalität zu hohen Aufwand bedeutet. Diese Integrationsmuster können mit den Mustern offen angebotener Dienst und veröffentlichte Sprache kombiniert werden, dabei wird in Kooperation ein Protokoll zum Austausch von gemeinsamen Modellen entwickelt.

Um den Überblick über die Bounded Contexts und die verwendeten Integrationsmustern nicht zu verlieren, ist die Kontextlandkarte ein wichtiges Artefakt. Sie stellt sowohl die Interaktion zwischen Bounded Contexts innerhalb des eigenen Projekts, wie auch Interaktionen mit externen Systemen dar. Es gibt keine einheitliche Repräsentation für Kontextlandkarten und auch ihr Detailgrad variiert (Rademacher, Sorgalla, and Sachweh 2018; Landre, Wesenberg, and Rønneberg 2006).

Die und zeigen zwei unterschiedliche Darstellung einer Kontextlandkarte. Beide wurden mit dem Modellierungswerkzeug ContextMapper (Kapferer 2020) aus dem gleichen Modell (Kapferer 2019) generiert und stellen eine Möglichkeit dar, die Bounded Contexts eines Frachtgütersystems zu organisieren.

[fig:ContextMap1]

[fig:ContextMap2]

Rollenbasierte Modellierung

Die Idee der rollenbasierten Modellierung stammt von Bachmann et al. (Bachman and Daya 1977) aus dem Jahre 1977 und wurde im Kontext der Datenbankmodellierung vorgeschlagen. Später wurde das Konzept von Rollen auf die objektorientierte Programmierung übertragen. Dort kann es in Form von Entwurfsmustern verwendet werden (Steimann and Stolz 2011; Bäumer et al. 1998). Es gibt auch Programmiersprachen mit Rollen als First-Class-Objekten, beispielsweise SCROLL (Leuthäuser and Aßmann 2015), einer Scala-Erweiterung oder Objectteams (Herrmann 2005), einer Java-Erweiterung.

Das Konzept von Rollen basiert darauf, dass Objekte sich in verschiedenen Kontexten unterschiedlich verhalten. Objekte können deshalb Rollen annehmen. Eine Rolle kann von mehreren Klassen gespielt werden, beispielsweise kann die Rolle Steuerung auf einem Containerschiff von einem Mensch oder von einem Computer gespielt werden. Diese Objekte können von unterschiedlichen Typen sein. Man sagt deshalb, dass Rollen nicht rigide sind. Es ist demzufolge, auch ohne Vererbung möglich, Polymorphie zu haben. Es handelt sich hierbei um Inklusions-Polymorphie (Steimann 2007). Ein Objekt kann mehrere Rollen spielen, beispielsweise kann ein Objekt Adresse sowohl die Rollen Startadresse, als auch Zieladresse spielen, beides sogar gleichzeitig. Ein Objekt kann auch die gleiche Rolle mehrmals spielen, dies ist zwar selten, aber man betrachte zum Beispiel einen Menschen, welcher zweimal die Rolle Angestellter spielt (Steimann 2007). Mit Rollen kann auch ein Sachverhalt modelliert werden, bei denen ein Objekt gleichzeitig zwei Rollen spielt, die das Objekt verändern können. Mit klassischer objektorientierter Modellierung ist das nur schwer möglich (Steimann and Stolz 2011). Beziehungen existieren nur zwischen Rollen.

Rollen werden zudem in Kontexten organisiert. Rollen und sogar Kontexte können selbst auch Rollen spielen. Wegen der Mehrdeutigkeit des Wortes Kontext wird es, in diesem Sinne, im Folgenden als Abteil bezeichnet (Kühn 2017).

Das Compartment Role Object Model

Es gibt eine Vielzahl von rollenbasierten Modellierungssprachen, die verschiedene Aspekte von Rollen modellieren können (Kühn et al. 2014). Diese Vielfalt ist zum Teil auch der Verwendung von Rollen in unterschiedlichen Bereichen geschuldet, beispielsweise in der Zugriffskontrolle (Sandhu et al. 1996), im Entwurf von Softwaresystemen (Steimann and Stolz 2011) und in der Datenorganisation (Bachman and Daya 1977; Steimann 2000). Mit CROM können viele der über Rollen bekannten Eigenschaften modelliert werden, mehr als bei anderen verbreiteten rollenbasierten Modellierungssprachen (Kühn et al. 2015).

CROM basiert auf Prädikatenlogik erster Stufe, wodurch formale Beweise, beispielsweise über Vollständigkeit und Konsistenz, möglich sind (Kühn et al. 2015; Böhme 2017). Außerdem gibt es visuelle Modellierungswerkzeuge für CROM (Kühn et al. 2016, 2018), die für Abbildungen in dieser Arbeit verwendet werden. zeigt diese graphische Notation.

Rollen existieren nur in Abteilen. Genauso wie Beziehungen zwischen Rollen nur innerhalb eines Abteils bestehen können. Beziehungen sind immer bidirektional. Die Spielt-Relation reicht über Abteilgrenzen hinweg. Natürliche Typen, Wert-Typen, Rollen-Typen und Abteil-Typen können Rollen spielen, wobei die Spielt-Relation nie aus einer Abteilung hinauszeigen darf. Zudem können verschiedene Einschränkungen bezüglich Kardinalitäten und der Nutzung der Spielt-Relation definiert werden.

Für Konzepte der rollenbasierten Modellierung ist eine Kategorisierung von Konzepten anhand der drei ontologischen Metaeigenschaften verbreitet: Rigidität, Abhängigkeit und Identität (Kühn et al. 2014; Almeida, Guizzardi, and Santos Jr 2009). Ein Objekt ist rigide, wenn es während seiner gesamten Lebenszeit seinen Typ nicht ändert. Ein Objekt heißt abhängig, wenn seine Existenz von der Existenz eines anderen Objekts abhängt. Außerdem kann ein Objekt eine eindeutige Identität, eine von anderen Objekten abgeleitete Identität oder keine eigene Identität besitzen. zeigt diese Kategorisierung.

Bestehende Ansätze zur Formalisierung von Domain-driven Design

Da DDD große Verbreitung gefunden hat, gibt es in der Praxis verschiedene Ansätze der DDD-Modellierung. Auch wissenschaftliche Arbeiten beschäftigen sich mit der DDD-Modellierung.

Rademacher et al. klassifizieren und quantifizieren die von Evans (Evans 2004) verwendeten UML-Elemente und stellen ein UML-Profil für DDD-Modellierungen bereit. Dafür identifizieren sie 25 notwendige Eigenschaften, die eine Modellierung haben muss, um nicht gegen Grundsätze des DDD zu verstoßen (Rademacher, Sachweh, and Zündorf 2017). Außerdem beschreiben sie die Anwendung ihres UML-Profils auf den strategischen Entwurf im Kontext von Microservice-Architekturen, sowie Herausforderungen, die dabei entstehen (Rademacher, Sorgalla, and Sachweh 2018). Aufbauend auf den Ideen von Rademacher et al. wurde ein UML-Profil von Schneider et al. entworfen, das besonderen Fokus auf den taktischen Entwurf legt. Das dabei entstandene UML-Profil ist in ein Modellierungswerkzeug integriert (Schneider et al. 2019). Eine spätere Arbeit (Hippchen et al. 2019) erweitert das UML-Profil um strategische Elemente. Zur Darstellung werden hauptsächlich UML-Komponentendiagramme verwendet.

Le et al. (Duc Minh Le, Duc-Hanh Dang, and Viet-Ha Nguyen 2016; Le, Dang, and Nguyen 2016) definieren eine domänenspezifische Sprache (DSL), die bei DDD-Modellierungen Domänenexpert:innen, Designer:innen und Programmierer:innen dabei unterstützt, an einem Modell kollaborativ zu arbeiten. Es werden Metaattribute als UML-Annotationen verwendet, um Anforderungen von Domänenexpert:innen zu erfassen, dabei fehlt aber inhaltlich ein klarer Bezug zu DDD.

Es gibt mehrere Arbeiten, die die Herausforderungen von DDD-Modellierung beschreiben, insbesondere im Kontext von Microservice-Architekturen (Rademacher, Sorgalla, and Sachweh 2018; Diepenbrock 2017). Mi­cro­ser­vice-Ar­chi­tekt­ur­en, stellen hohe Anforderungen an eine gute Modellierung, da im Gegensatz zu einem De­ploy­ment-Mo­no­li­then die Übersicht über verschiedene Teile des Systems herausfordernder ist. Als Herausforderungen werden unter anderen die Kollaboration von mehreren Ent­wic­kler:in­nen­teams an einem Modell, die Kommunikation zwischen den Bounded Contexts und die fehlende Formalisierung von DDD identifiziert.

Für den strategischen Entwurf gibt es Modellierungswerkzeuge und wissenschaftliche Arbeiten zu diesen. Ajil (Sorgalla 2017) bietet dafür einen graphischen Editor mit zugrundelegendem formales Modell, allerdings nicht für DDD allgemein, sondern nur für DDD-Microservice-Architekturen. Insbesondere kann der Übergang zwischen abstrakter Übersicht und konkreten Protokollen übersichtlich dargestellt werden. Es gibt momentan noch keine automatische Konsistenthaltung von Quelltext und Entwurf (Rademacher, Sorgalla, and Sachweh 2018). ContextMapper (Kapferer 2020) hingegen bietet eine solche Konsistenthaltung. ContextMapper kann basierend auf einer DSL verschiedene Diagrammtypen erzeugen. Darunter sind Kontextlandkarten wie in den Abbildungen [fig:ContextMap1] und 2 dargestellt, aber auch UML-Klassendiagramme, einzelner Bounded Contexts.

Keiner der bestehenden Ansätze gibt eine Übersicht über den Inhalt und das verwendete Integrationsmuster bei geteilten Konzepten. Beim Entwurf ist aber von Interesse, welche Konzepte wo verwendet werden und wer diese verändern kann (Kapferer 2020). Die in dieser Arbeit vorgestellte Abbildung bietet eine solche Übersicht.

Konzept zur Formalisierung von Domain-driven Design durch Abbildung in die rollenbasierte Modellierung

Als ersten Schritt hin zu einer Abbildung werden konzeptionell ähnliche Bestandteile von DDD und rollenbasierter Modellierung gesucht. Die Begrifflichkeiten der rollenbasierten Modellierung und des DDD weisen wenig Ähnlichkeit auf. Als Kriterium für Ähnlichkeit bedarf es grundlegender Eigenschaften der Konzepte. Dabei werden Eigenschaften benötigt, die Konzepte unabhängig von Begrifflichkeit oder Implementierung vergleichbar machen. Hier kann die Kategorisierung nach den in verwendeten ontologischen Metaeigenschaften für die Konzepte des DDD angewendet werden. Zunächst ist festzustellen, dass alle Konzepte des DDD rigide sind, ihr Typ ändert sich also während ihrer Lebenszeit nicht. klassifiziert die zentralen Konzepte des DDD entsprechend.

Datenobjekte in DDD haben keine eigene Identität. Ihre Identität leitet sich lediglich aus der Gesamtheit ihrer Attribute ab. Durch die Unveränderlichkeit der Datenobjekte, können sie bei Bedarf neu erzeugt oder kopiert werden. Für den Benutzer ist das unerheblich, da er wegen der fehlenden eindeutigen Identität, einzelne Datenobjekte nicht unterscheiden kann. Konzeptionell existieren alle Ausprägungen jedes Datenobjekts zu jeder Zeit. Durch diese Eigenschaften ist die Abbildung eines Datenobjekts auf einen Wert in der rollenbasierten Modellierung die natürliche Wahl. Entitäten haben eine eindeutige Identität. Diese kann entweder global, innerhalb des Bounded Context oder nur innerhalb eines Aggregats eindeutig sein. Entitäten sind in dem Sinne abhängig, dass ihre Existenz von der Existenz des Bounded Contexts abhängt. Wie in beschrieben, kann es für eine Sache unterschiedliche Modelle in unterschiedlichen Bounded Contexts geben. Wobei Teile des Modells zwischen Bounded Contexts mittels Integrationsmustern geteilt werden. In der rollenbasierten Modellierung kann das mittels eines rigiden Typs erzielt werden, der eine Rolle spielt. Deshalb ist eine Abbildung wie in dargestellt sinnvoll. Wird eine Entität nicht geteilt, besteht nur eine Spielt-Relation in einen Bounded Context. Geteilte Datenobjekte können auf gleiche Art, entsprechend mit Datenobjekten, dargestellt werden.

Bounded Contexts sind, wie bereits in angesprochen, nur über die ubiquitäre Sprache definiert und bilden einen Rahmen um enthaltene Objekte. Für diese Arbeit wird ein Bounded Context als etwas Konkreteres angesehen. Ein Bounded Context soll insbesondere instanziierbar sein. Wird ein Bounded Context instanziiert, wird die minimal benötigte Menge an enthaltenen Konzepten erstellt. Dies ist vor allem im Bereich von Microservices eine sinnvolle Annahme. Dort entsprechen einzelne Bounded Contexts oftmals einzelnen Microservices. Diese müssen auch instanziiert und sinnvoll initialisiert werden. Damit können Bounded Contexts durch Abteile abgebildet werden. Diese erfüllen die angenommenen Eigenschaften von Instanziierbarkeit und minimaler Initialisierung. Außerdem stimmen auch die, in den Tabellen 1 und 2, festgestellten Eigenschaften überein. Ein Aggregat ist im gleichen Sinne von einem Bounded Context abhängig und kann in diesem Zusammenhang wie eine Entität angesehen werden. Seine Identität ist von der Entität abgeleitet, die die Wurzel bildet. Da ein Aggregat außerdem Objekte kapselt, passt es zu einem Abteil. Abteile können selbst Teil eines Abteils sein. Da die Spielt-Relation nicht aus Abteilen heraus zeigen kann, werden die geteilten Aggregate außerhalb des Abteils, des Bounded Contexts notiert. Depots sind schwieriger zu klassifizieren und zuzuordnen. Ein Depot hat eine eindeutige Identität und ist abhängig vom Bounded Context und den darin enthalten Objekten auf die es Zugriff gewährt. Depots können in verschiedenen Situationen eingesetzt werden. Zum einen als Schnittstelle für einen Bounded Context nach außen, zum anderen als Stellvertreter zu einer permanenten Datenspeicherung innerhalb eines Bounded Context. Hat ein Bounded Context nur eine einzige Schnittstelle, wären Methoden im Abteil des Bounded Context eine gute Darstellung. Für komplexere Bounded Contexts mit mehreren Schnittstellen wird dies allerdings unübersichtlich und die Trennung zwischen den Schnittstellen gestaltet sich schwieriger. Die ontologische Fundierung eines Depots stimmt mit der eines Abteils überein. Außerdem beinhaltet ein Depot Objekte und bietet dafür eine Schnittstelle nach außen, genau wie ein Abteil, dass Rollen beinhaltet und für das Methoden definiert werden können. Lokale Depots können, wie lokale Aggregate, als Abteil in einem Abteil, dem Bounded Context, dargestellt werden. Dienste und Fabriken sind zustandslos und implementieren Funktionalität, die von anderen verwendet werden kann. Ähnlich wie bei Datenobjekten ist es unerheblich wie viele Instanzen von einem Dienst oder einer Fabrik existieren und welche davon verwendet werden. In der Praxis können Dienste und Fabriken deshalb als Einzelstücke (Gamma et al. 1994) implementiert oder über ein Dienstverzeichnis bereitgestellt werden. In CROM gibt es allerdings keine direkte Darstellung von Einzelstücken. Dienste und Fabriken können wie Datenobjekte als Wert-Typ abgebildet werden, der eine Rolle spielt, wobei die Rollen nur Methoden und keine Attribute haben und der Wert-Typ nur identitätsstiftend ist. Bei geteilten Diensten und Fabriken muss die Funktionalität in den Wert-Typ verschoben werden. Module gruppieren zusammengehörige Teile eines Bounded Context in DDD. Sie sind nicht instanziierbar und zum Beispiel mit Paketen in Java implementierbar. Module haben daher ähnliche Eigenschaften wie Gruppen in CROM, auch da mit Gruppen Bedingungen für das gesamte Modul definiert werden können. gruppiert die in diesem Absatz als verwandt identifizierten Konzepte und bietet somit die Grundlage für die konkrete Implementierung der Abbildung im folgenden Abschnitt.

Realisierung einer Abbildung von Domain-driven Design in das Compartment Role Model

Dieser Abschnitt beschreibt zuerst die Abbildung der Muster auf der taktischen Ebene, danach wird auf die Darstellung von Integrationsmustern eingegangen.

Taktische Ebene und Bounded Contexts

Abteile stellen Bounded Contexts dar. Die Inhalte eines Bounded Context werden als Rollen dargestellt, wobei für jede Rolle eine minimale Kardinalität angegeben ist. Somit kann der Bounded Context bei Initialisierung eine minimale Menge von Inhalten erzeugen, die er braucht, um gültig zu sein. Entitäten innerhalb eines Bounded Contexts werden durch eine Rolle in dem Abteil mit einem entsprechenden natürlichen Typ außerhalb des Abteils dargestellt. Gleiches gilt für Datenobjekte, nur dass bei diesen statt eines natürlichen Typs ein Wert-Typ verwendet wird. Eine andere Art, Datenobjekte darzustellen, sind Attribute von Rollen, die diese benutzen. Einige Datentypen können auch als Attribute dargestellt werden. Wie auch in UML, ist die Wahl zwischen einer Assoziation (Beziehungs-Typ) und einem Attribut nicht eindeutig zu treffen. Aus diesem Grund wird die für den ursprünglichen Entwurf getroffene Entscheidung nicht geändert, obwohl dadurch Rollen entstehen, die besser anders modelliert werden sollten, da sie nicht im eigentlichen Sinne dem Rollenbegriff entsprechen. In beiden Fällen stellt sich die Frage, welche Attribute und Methoden der Rolle und welche dem rigiden Typ zugeordnet werden sollen. Grundsätzlich müssen alle Teile eines Modells, die geteilt werden, in den rigiden Typ geschrieben und alle Teile, die nur den aktuellen Kontext betreffen, in die Rolle geschrieben werden. Da sich in vielen Fällen die Anforderungen an ein System im Laufe der Zeit ändern, kann dafür keine allgemeine Regel angegeben werden. Es sollte initial so wenig wie möglich im rigiden Typ stehen, da dies eine spätere Entwurfsänderung erleichtert. Bei einer Entität könnte beispielsweise nur seine ID im natürlichen Typ stehen. Beziehungs-Typen zwischen Entitäten und Wert-Objekten werden aus dem objektorientierten Entwurf von den Assoziationen übernommen und bestehen nun zwischen den Rollen.

Ein Aggregat wird durch ein Abteil dargestellt. In diesem gibt es eine ausgezeichnete Rolle, die die Wurzel des Aggregats darstellt. Wie bei Bounded Contexts, werden auch hier Kardinalitäten angegeben, um bei Initialisierung eine gültige Anzahl von Objekten vorzufinden. Aggregate in DDD werden verwendet, um Konsistenz zwischen Objekten zu garantieren. CROM kann Konsistenzbedingungen auf der Ebene von Kardinalitäten und der Spielt-Relation darstellen und validieren, komplexere Bedingungen müssen, wie in UML, textuell dargestellt werden. Eingehende Assoziationen bei einem Aggregat in DDD müssen auf das Wurzelobjekt gerichtet sein, wobei alle Objekte in einem Aggregat Assoziationen nach außen haben dürfen. Die ursprüngliche Klassenhierarchie wird innerhalb des Abteils in Form von Rollen dargestellt. Verwendet wird das Aggregat durch eine Rolle, die von dem Abteil gespielt wird. Zum einen werden Assoziationen zu allen Stellen im Bounded Context benötigt, die Assoziationen zur Wurzel des Aggregats hatten. Zum anderen gehen von dieser zentralen Rolle Assoziationen zu allen Objekten aus, die von innerhalb des Aggregats verwendet werden. Dies ist möglich, da jede Assoziation als eine delegierende Methode dargestellt werden kann. Hierbei müssen die Kardinalitäten entsprechenden angepasst werden, da nun mehrere Assoziationen in einer zusammengefasst werden, wie in den Abbildungen [fig:aggregate] und 6 dargestellt. Dies ist eine Limitation der Abbildung, da dadurch Informationen verloren gehen. Aggregate, die nur lokal in einem Bounded Context verwendet werden, könnten Teil des Bounded-Context-Aggregat sein. Dies würde es erlauben, dass die Rollen im Aggregat von Rollen des umgebenden Abteils gespielt werden. Da dies aber an keinem Punkt in der Abbildung benötigt wird und es für die Implementierung von Depots einfacher ist, befinden sich alle Aggregate außerhalb der Abteile des umgebenden Bounded Context.

[fig:aggregate]

[fig:aggregateCROM]

Dienste und Fabriken werden als Wert-Typen dargestellt, dieser spielt an der benötigten Stelle im Bounded Context eine Rolle, wie bereits in beschrieben. Bei beiden ist der Wert-Typ leer und nur identitätsstiftend. Wird ein Dienst oder eine Fabrik geteilt, müssen die Methoden in den Wert-Typ geschrieben werden. Dadurch ist es auch möglich, einen Dienst mit verschiedenen Schnittstellen an verschiedenen Orten zu realisieren, indem die Rolle als Adapter fungiert. Wie in beschrieben, werden Fabriken mit klassischen objektorientierten Entwurfsmustern realisiert. Für diese gibt es rollenbasierte Adaptionen (Riehle 1997). Geteilte Depots werden durch die Variante aus dargestellt, bei der ein Depot existiert, dessen Rollen von den Bounded Contexts und Aggregaten gespielt werden, auf die Zugriff gewährt werden soll. Die Abfragen, die das Depot bereitstellt, werden durch Methoden im Abteil dargestellt. Die Rollen im Aggregat werden von den zugehörigen Typen gespielt. Dies Typen können auch Aggregate sein. Durch Kardinalitäten über den Rollen im Depot können Angaben über Anzahl der dort gespeicherten Objekte genacht werden, standardmäßig beliebig viele. Das Abteil spielt am Ort der Verwendung eine (leere) Rolle.

Wie in angesprochen, werden auch in DDD Rollen verwendet. Evans und Rademacher et al. (Evans 2004; Rademacher, Sachweh, and Zündorf 2017) stellen diese als quallifizierte Assoziation (vlg. ) dar. Diese werden zu Rollen abgebildet, die von einem natürlichen Typ gespielt werden.

Bei der Anwendung der Abbildung ist die Reihenfolge wichtig, in der einzelne Konzepte abgebildet werden. Die Abbildung funktioniert top-down, das heißt zuerst werden die Bounded Contexts abgebildet, danach Aggregate, Depots, Dienste und Fabriken, dann geteilte Entitäten und Datenobjekte.

Die Abbildung muss top-down durchgeführt werden, da sich die einzelnen Schritte auf übergeordnete Ebenen beziehen und da übergeordnete Ebenen aus untergeordneten Ebenen bestehen. Ein Aggregat besteht beispielsweise aus Entitäten und Wert-Objekten.

Integrationsmuster

Austausch zwischen Bounded Contexts findet in DDD über Integrationsmuster statt. Wie in beschrieben, ist es wünschenswert im Entwurf zu sehen, an welcher Stelle welches Muster eingesetzt wurde. Dieser Abschnitt beschreibt, wie sich die Integrationsmuster konform zur gerade definierten Abbildung umsetzten lassen. Außerdem werden Konventionen vorgeschlagen, um die Übersicht im Entwurf zu erhöhen.

In der beschriebenen Abbildung ist, durch die Spielt-Relation ersichtlich, welche Konzepte ausgetauscht werden. Sobald diese in mehrere Bounded Contexts zeigt, wird ein Konzept geteilt. Somit ist das Integrationsmuster getrennte Wege, das der Standardfall ist, schon durch die Abwesenheit von solchen Verbindungen zwischen zwei Bounded Contexts zu erkennen. Für die Partnerschaft-Beziehung bietet sich die Konvention an, die geteilten Modelle in die Mitte zwischen die Bounded Contexts zu schreiben. Die Teams von beiden Bounded Contexts haben also gleichermaßen Einfluss auf die geteilten Modelle. Gleich verhält es sich bei einem geteilten Kern, der sich zur Partnerschaft nur durch die Menge der geteilten Modelle unterscheidet. Dieser Logik folgend, werden bei einer Kunde-Lieferant-Beziehung die geteilten Modelle näher beim Lieferanten notiert. Der Lieferant bestimmt die Modelle und der Kunde hat nur mittelbar Einfluss auf diese. Beim Integrationsmuster Konformist befinden sich die geteilten Modelle dann direkt an einem Bounded Context, der andere Bounded Context hat also keinen Einfluss auf diese. Das Integrationsmuster Antikorruptionsschicht bildet einen Adapter (Gamma et al. 1994) zwischen Bounded Contexts. Es wird das von einem Bounded Context definierte Modell transformiert, um es den eigenen Bedürfnissen anzupassen. Betrachte einen Bounded Context BC1 der ein Modell M1 verwendet und einen zweiten Bounded Context BC2, der sich durch eine Antikorruptionsschicht schützen will. Statt dass BC2 M1 nutzt, werden neue rigide Typen verwendet, die Rollen im alten Modell spielen.

Aus Gründen der Übersichtlichkeit und der klaren Unterscheidbarkeit, werden gepunktete Linien um die zusammengehörigen Konzepte gezeichnet. An den gepunkteten Linien wird die Art des Integrationsmusters und gegebenenfalls, zum Beispiel bei einer geteilten Sprache, dessen Namen notiert. Diese Konvention ist nicht Teil von CROM und hat keine weiteren Auswirkungen auf das Modell.

Fallstudie zur Evaluation der gefundenen Abbildung

Fragestellung

In diesem Abschnitt wird die beschriebene Abbildung evaluiert. Hierbei wird an einem Beispiel untersucht werden, ob die Abbildung zweckmäßig ist. Sowohl die Wohlgeformtheit, als auch die Vollständigkeit der Abbildung werden untersucht, um eine grundsätzlich anwendbare Abbildung zu haben. Außerdem wird exemplarisch geprüft, ob die Abbildung die in geforderte Übersichtlichkeit aufweist. Es soll sowohl eine Übersicht über verschiedene Bounded Contexts gegeben, sowie die geteilten Modelle sichtbar gemacht werden.

Methodik zur Anwendung der Abbildung

Es wird von einem DDD-Entwurf ausgegangen und dieser dann der Abbildung folgend in eine rollenbasierte Darstellung umgewandelt. Wie schon zuvor wird von einem Frachtgütersystem als Beispiel ausgegangen. Es handelt sich dabei um ein Standardbeispiel, das initial von Evans (Evans 2004) verwendet wurde. Auch Rademacher et al. (Rademacher, Sachweh, and Zündorf 2017; Rademacher, Sorgalla, and Sachweh 2018) haben das Beispiel verwendet, um ihre Formalisierung zu demonstrieren. Das Frachtgütersystem-Beispiel in Evans Buch ist nicht vollständig definiert, da verschiedene Iterationen und Ausschnitte beschrieben werden. Um Vergleichbarkeit und eine klar definierte Ausgangslage zu haben, wird deshalb genau das Beispiel aus (Rademacher, Sachweh, and Zündorf 2017) verwendet, wie es in dargestellt ist. Im folgenden wird Schrittweise vorgegangen, um zu einem rollenbasierten Entwurf in CROM zu gelangen. diesen Entwurf.

Bounded Contexts werden zuerst in Abteile umgewandelt, es gibt also die Abteile Cargo, Customer, und Location. Um Namenskollisionen zu vermeiden und um bessere Unterscheidbarkeit zu erreichen, werden an die Namen aus ein „T“ für rigide Typen angehängt. Das Cargo-Aggregat wird abgebildet, indem an dessen Stelle im CargoBoundedContext Abteil eine Rolle Cargo eingeführt wird. Die Cargo-Rolle wird von einem Abteil, CargoAggregateT gespielt. Der LocationService ist ein geteilter Dienst. Er wird also als Wert-Typ mit Methoden dargestellt, der eine Rolle an der Stelle spielt, an der er verwendet wird. Der LocationService ist ein geteilter Dienst, er wird deshalb als Wert-Typ mit entsprechenden Methoden modelliert. Der Dienst wird im CargoAggregateT verwendet, deshalb existiert dort eine Rolle, die vom LocationServiceT-Abteil gespielt wird. Das Gleiche passiert mit dem CustomerRepository. Das CargoRepository ist in dem hier gezeigten Systemausschnitt lokal und wird deshalb als Abteil im CargoBoundedContext dargestellt. Das Depot wird an keiner Stelle verwendet, das Abteil spielt also keine Rolle. Die enthaltene Rolle wird vom CargoAggregateT gespielt. Die geteilten Entitäten LocationShared und CustomerShared werden durch natürliche Typen dargestellt, die Rollen an den Stellen spielen, an denen sie verwendet werden. Bei der CustomerShared-Assoziation handelt es sich, um eine Rollen-Beziehung in DDD. Aus der qualifizierten Assoziation in wird nicht ersichtlich welche Rollen Customer spielt. Evans Buch (Evans 2004) gibt darüber Aufschluss. Es gibt unter anderem die Rollen Payer, Shipper, Receiver und weiter nicht genannte. Als letztes werden die lokalen Entitäten und Wert-Typen abgebildet, indem Rollen eingeführt werden mit zugehörigen natürlichen Werttypen und Datentypen. IDs von Entitäten werden in den natürlichen Typen notiert. Die Beziehungen ergeben sich aus dem UML-Entwurf. Die Assoziation von DeliverySpecification zu HandlingEvent, geht nicht von dem Wurzelelement des Cargo-Aggregats aus, deshalb wird sie auf eine Assoziation zwischen den Rollen CargoAggregate und HandlingEvent im CargoBoundedContext abgebildet. Außerdem gibt keinen Aufschluss über die minimalen Kardinalitäten, die in einem Bounded Context oder Aggregat vorhanden sein müssen. Außerdem gibt es keine Angaben zu den verwendeten Integrationsmustern, deshalb wurden hier jeweils ein offen angebotener Dienst mit veröffentlichte Sprache angenommen.

Ergebnisse der Fallstudie

Jedes, der in dargestellten Konzepte kann in CROM dargestellt werden, mit Ausnahme der <<use>>-Beziehungen. Dabei handelt es sich jedoch um ein nicht sehr umfangreiches Beispiel, in welchem einige DDD-Konzepte überhaupt nicht vorkommen. Außerdem nimmt das Beispiel eine sehr abstrakte Sicht des Systems ein, bei der die taktische Entwurfsebene nur wenig untersucht wurde. Für beide Entwürfe sind also noch weitere Entwurfsschritte notwendig, bevor das System implementiert werden kann. Über die Vollständigkeit der Abbildung liegt also wenig Evidenz vor. Gleiches gilt für die Wohlgeformtheit, für die in diesem Beispiel kein Gegenbeispiel gefunden wurde. Weitere, größere Fallstudien sind also notwendig, um andere Aspekte zu beleuchten. Eine Evaluation der Abbildung durch einen formalen Beweis zur Semantikerhaltung ist aufgrund der fehlenden formalen Grundlage von DDD nicht möglich. Weiter ist anzumerken, dass die Abbildung keinen perfekten rollenbasierten Entwurf in irgendeinem Sinne liefert. Es geht lediglich darum, eine grundsätzliche Abbildbarkeit zu haben. In wurden einige Optimierungen angesprochen, die den Entwurf in manchen Fällen übersichtlicher machen. Hier wurde für die Fallstudie immer der allgemeinste Fall gewählt.

Zukünftige Forschung und Fazit

Diese Arbeit zeigt, dass CROM grundsätzlich als formale Modellierungssprache für DDD verwendet werden kann. Die Abbildung wurde so konzipiert, dass Zusammenhänge zwischen strategischer und taktischer Ebene sichtbar gemacht werden. Die Fallstudie dient dabei als Beispiel für die Anwendung der Abbildung. Weitere Forschung kann dabei an mehreren Stellen anknüpfen. Ein natürlicher Schritt ist es, die hier abstrakt beschriebene Abbildung zu einer automatischen Modelltranformation zu erweitern. Hierbei kann von einem der in aufgezählten UML-Profile ausgegangen werden, um eine Modelltransformation nach CROM zu erreichen. Diese Arbeit ist nur von Konzepten als Urbilder ausgegangen, die im ursprünglichen Buch von Evans vorhanden waren. In der Zwischenzeit wurden insbesondere Ereignisse als neue Konzepte in DDD eingeführt (Vernon 2013; Evans 2014). Zukünftige Forschung kann die hier beschriebene Abbildung um dieses und andere neue Konzepte erweitern. Außerdem wurden einige Konzepte und Bounded Contexts als konkrete instanziierbare Konzepte nur angesprochen, aber nicht näher beleuchtet. CROM bietet neben der Formalisierung auch den Vorteil, dass aus nur wenigen Konzepten besteht, im Gegensatz zu dem sehr umfangreichen UML, dies führt zu einfach verständlichen Entwürfen. An einigen Stellen könnte eine Erweiterung von CROM allerdings neue Möglichkeiten eröffnen. Ein hilfreiches Konzept wären beispielsweise Einzelstücke. Obwohl insbesondere die nicht vollständige Abbildbarkeit von Beziehungen zu Aggregaten eine Limitationen darstellt, ist zu vermuten, dass andere Aspekte des DDD besser als in UML darstellbar werden, wie beispielsweise der rollenbasierte Anteil in DDD oder die grundsätzliche Idee, dass für ein Konzept mehrere Modelle existieren.