Skip to main content
Wachter Space 🚀
  1. Posts/

Rollenbasierter Modellierung fĂŒr das Domain-driven Design

Table of Contents

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.

image [fig:ContextMap1]

image [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.

Graphische Notation von CROM. Entnommen aus (KĂŒhn 2017) Abbildung 7.1

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.

Kategorisierung von CROM-Konzepten anhand der ontologischen Metaeigenschaften: RigiditĂ€t, AbhĂ€ngigkeit und IdentitĂ€t. Inhalt entnommen aus (KĂŒhn 2017), Tabelle 7.1[roleCat].
KonzeptrigideabhÀngigIdentitÀt
KonzeptrigideabhÀngigIdentitÀt
natĂŒrlicher Typjaneineindeutig
Wert-Typjaneinabgeleitet
Rollen-Typneinjaabgeleitet
Abteil-Typjajaeindeutig
Beziehungs-Typjajaabgeleitet (zusammengesetzt)

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.

Kategorisierung von Konzepten des DDD anhand der ontologischen Metaeigenschaften AbhÀngigkeit und IdentitÀt.[dddCat]
KonzeptabhÀngigIdentitÀt
KonzeptabhÀngigIdentitÀt
Datenobjektneinabgeleitet
EntitÀtjaeindeutig
Aggregatjaabgeleitet
Depotjaeindeutig
Dienst, Fabrikneinabgeleitet
Bounded Contextjaabgeleitet

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.

Abbildung einer EntitĂ€t durch einen natĂŒrlichen Typ und eine Rolle. Die Bouned Contexts sind informell angedeutet.

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.

Abbildung von Konzepten des DDD auf Konzepte der rollenbasierten Modellierung.[mappingTab]
UrbildVorkommenBild
UrbildVorkommenBild
Datenobjektnicht geteiltWert-Typ, der eine Rolle spielt
DatenobjektgeteiltWert-Typ, der mehrere Rolle spielt
EntitĂ€tnicht geteiltnatĂŒrlicher Typ, der eine Rolle spielt
EntitĂ€tgeteiltnatĂŒrlicher Typ, der mehrere Rolle spielt
AggregatgeteiltAbteil, das eine Rolle spielt
Aggregatnicht geteiltAbteil in einem Abteil
DepotgeteiltAbteil
Depotnicht geteiltAbteil in einem Abteil
Dienst, FabrikgeteiltWert-Typ mit Methoden, der eine leere Rolle spielt
Dienst, Fabriknicht geteiltleerer Wert-Typ, der eine Rolle spielt
ModulallgemeinGruppe
Bounded ContextallgemeinAbteil

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.

image [fig:aggregate]

image [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.

Ausschnitt aus dem DDD-Beispiel von (Evans 2004). Ausgangspunkt fĂŒr diese Fallstudie. Entnommen aus (Rademacher, Sachweh, and ZĂŒndorf 2017), Abbildung 3.

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.

image [fig:dddcrom]

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.

Almeida, Joao Paulo, Giancarlo Guizzardi, and Paulo Sergio Santos Jr. 2009. “Applying and Extending a Semantic Foundation for Role-Related Concepts in Enterprise Modelling.” Enterprise Information Systems 3 (3): 253–77.

Bachman, Charles W, and Manilal Daya. 1977. “The Role Concept in Data Models.” In Proceedings of the Third International Conference on Very Large Data Bases-Volume 3, 464–76.

BĂ€umer, Dirk, Dirk Riehle, Wolf Siberski, and Martina Wulf. 1998. “The Role Object Pattern.” In Washington University Dept. Of Computer Science.

Böhme, Stephan. 2017. “Context Reasoning for Role-Based Models.” PhD thesis, Technische UniversitĂ€t Dresden.

Bugiotti, Francesca, Luca Cabibbo, Paolo Atzeni, and Riccardo Torlone. 2014. “Database Design for Nosql Systems.” In International Conference on Conceptual Modeling, 223–31. Springer.

Diepenbrock, Florian AND Sachweh, Andreas AND Rademacher. 2017. “An Ontology-Based Approach for Domain-Driven Design of Microservice Architectures.” In INFORMATIK 2017, edited by Martin Eibl Maximilian AND Gaedke, 1777–91. Gesellschaft fĂŒr Informatik, Bonn.

Duc Minh Le, Duc-Hanh Dang, and Viet-Ha Nguyen. 2016. “Domain-Driven Design Using Meta-Attributes: A Dsl-Based Approach.” In 2016 Eighth International Conference on Knowledge and Systems Engineering (Kse), 67–72.

Evans, Eric. 2004. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional.

———. 2014. Domain‐Driven Design Reference: Definitions and Pattern Summaries. Dog Ear Publishing.

Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. 1994. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley.

Hakin, Kamil. 2010. “Correctness for Cqrs Systems.” Master’s thesis, KTH Royal Institute of Technology, Stockholm.

Herrmann, Stephan. 2005. “Programming with Roles in Objectteams/Java.” In Proc. AAAI Fall Symposium.

Hippchen, Benjamin, Michael Schneider, Pascal Giessler, and Sebastian Abeck. 2019. “Systematic Application of Domain-Driven Design for a Business-Driven Microservice Architecture.” International Journal on Advances in Software Volume 12, Number 3 & 4, 2019.

Kapferer, Stefan. 2019. “Context-Mapper-Examples.” https://github.com/ContextMapper/context-mapper-examples/tree/master/src/main/cml/ddd-sample.

———. 2020. “A Modeling Framework for Strategic Domain-Driven Design and Service Decomposition.” HSR Hochschule fĂŒr Technik Rapperswil.

KĂŒhn, Thomas. 2017. “A Family of Role-Based Languages.” PhD thesis, Technische UniversitĂ€t Dresden.

KĂŒhn, Thomas, Kay Bierzynski, Sebastian Richly, and Uwe Aßmann. 2016. “FRaMED: Full-Fledge Role Modeling Editor (Tool Demo).” In Proceedings of the 2016 Acm Sigplan International Conference on Software Language Engineering, 132–36. SLE 2016. Association for Computing Machinery.

KĂŒhn, Thomas, Stephan Böhme, Sebastian Götz, and Uwe Aßmann. 2015. “A Combined Formal Model for Relational Context-Dependent Roles.” In Proceedings of the 2015 Acm Sigplan International Conference on Software Language Engineering, 113–24.

KĂŒhn, Thomas, Kevin Ivo Kassin, Walter Cazzola, and Uwe Aßmann. 2018. “Modular Feature-Oriented Graphical Editor Product Lines.” In Proceedings of the 22nd International Systems and Software Product Line Conference - Volume 1, 76–86. SPLC ’18. Association for Computing Machinery.

KĂŒhn, Thomas, Max LeuthĂ€user, Sebastian Götz, Christoph Seidl, and Uwe Aßmann. 2014. “A Metamodel Family for Role-Based Modeling and Programming Languages.” In International Conference on Software Language Engineering, 141–60. Springer.

Landre, Einar, Harald Wesenberg, and Harald Rþnneberg. 2006. “Architectural Improvement by Use of Strategic Level Domain-Driven Design.” In Companion to the 21st ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications - OOPSLA 06, 809–14. ACM Press.

Le, D. M., D. Dang, and V. Nguyen. 2016. “Domain-Driven Design Patterns: A Metadata-Based Approach.” In 2016 Ieee Rivf International Conference on Computing Communication Technologies, Research, Innovation, and Vision for the Future (Rivf), 247–52.

LeuthĂ€user, Max, and Uwe Aßmann. 2015. “Enabling View-Based Programming with Scroll: Using Roles and Dynamic Dispatch for Etablishing View-Based Programming.” In Proceedings of the 2015 Joint Morse/Vao Workshop on Model-Driven Robot Software Engineering and View-Based Software-Engineering, 25–33.

Rademacher, Florian, Sabine Sachweh, and Albert ZĂŒndorf. 2017. “Towards a Uml Profile for Domain-Driven Design of Microservice Architectures.” In International Conference on Software Engineering and Formal Methods, 230–45. Springer.

Rademacher, Florian, Jonas Sorgalla, and Sabine Sachweh. 2018. “Challenges of Domain-Driven Microservice Design: A Model-Driven Perspective.” IEEE Software 35 (3): 36–43.

Riehle, Dirk. 1997. “A Role-Based Design Pattern Catalog of Atomic and Composite Patterns Structured by Pattern Purpose.” Ubilab Technical Report 97.1. 1. ZĂŒrich, Switzerland: Union Bank of Switzerland.

Sandhu, Ravi S, Edward J Coyne, Hal L Feinstein, and Charles E Youman. 1996. “Role-Based Access Control Models.” Computer 29 (2): 38–47.

Schneider, Michael, Benjamin Hippchen, Pascal Giessler, Chris Irrgang, and Sebastian Abeck. 2019. “Microservice Development Based on Tool-Supported Domain Modeling.” In The Fifth International Conference on Advances and Trends in Software Engineering.

Schön, Hendrik, Susanne Strahringer, Frank Furrer, and Thomas KĂŒhn. 2019. “Business Role-Object Specification: A Language for Behavior-Aware Structural Modeling of Business Objects.” In.

Sorgalla, Jonas. 2017. “Ajil: A Graphical Modeling Language for the Development of Microservice Architectures.” In Extended Abstracts of the Microservices 2017 Conference.

Steimann, Friedrich. 2000. “A Radical Revision of Uml’s Role Concept.” In International Conference on the Unified Modeling Language, 194–209. Springer.

———. 2007. “The Role Data Model Revisited.” Applied Ontology 2 (2): 89–103.

Steimann, Friedrich, and Fabian Urs Stolz. 2011. “Refactoring to Role Objects.” In Proceedings of the 33rd International Conference on Software Engineering, 441–50.

Vernon, Vaughn. 2013. Implementing Domain-Driven Design. Addison-Wesley.

Wirfs-Brock, Rebecca, and Alan McKean. 2003. Object Design: Roles, Responsibilities, and Collaborations. Addison-Wesley Professional.

Wlaschin, Scott. 2018. Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#. Pragmatic Bookshelf.