DDD: Amazing!

Einführung in die Konzepte von Domain-driven Design

Martin Kernland, Adrian Gygax

©Shutterstock/Profit_Image

Domain-driven Design – kurz DDD – erfährt in der aktuellen Diskussion um Softwarearchitektur eine hohe Aufmerksamkeit. Das Anfang der 2000er geprägte Konzept gilt insbesondere als eine der Grundlagen-Theorien für Microservices-Architekturen. Auf JAXenter wollen wir der DDD-Idee deshalb in einer Themenwoche genauer auf den Grund gehen. Zur Einführung in die Konzepte von Domain-driven Design präsentieren wir den folgenden Artikel „DDD Amazing!“, in dem die fiktive Firma Amazine ihre Systemlandschaft mit Hilfe von DDD neu ordnet.

DDD: Amazing!

Die fiktive Firma Amazine hat ein Problem: Das Geschäft wird gebremst durch die IT-Systemlandschaft, die auf ändernde Anforderungen nicht rasch genug reagieren kann. Lernen Sie zusammen mit Amazine, wie die Anwendung von Domain-driven Design eine Systemlandschaft in Schwung bringt.

Einführung in die Konzepte von Domain-driven Design

Stellen Sie sich vor, Sie müssten ein komplexes Softwaresystem oder sogar eine komplexe Applikationssystemlandschaft flexibler und robuster machen. Egal welche Rolle Sie haben, sei es als Projektleiter, Softwarearchitekt, Businessanalyst oder gar CIO, für diese Aufgabe benötigen Sie unterschiedliche Leute mit unterschiedlichen Fähigkeiten. In diesem Artikel werden einige Herausforderungen aus Sicht des Softwarearchitekten geschildert. Die Rolle des Architekten wird je nach Unternehmen unterschiedlich ausgelegt. Wir möchten hier eine möglichst ganzheitliche Betrachtung dieser Rolle aufzeigen und auf drei unterschiedliche Ebenen der Architektur eingehen: die Unternehmensarchitektur, die Systemarchitektur und die Implementationsebene. Dazu bringen wir einige Aspekte von Domain-driven Design ein und zeigen auf, wie man damit Architekturen robuster und gleichzeitig flexibler machen kann und zwar auf allen drei erwähnten Ebenen.

Domain Driven Design im Videotutorial

Im entwickler.tutorial Domain-Driven Design, führt Hennig Schwentner Sie Schritt für Schritt durch das komplexe DDD-Themengebiet: Event Storming, Strategic Design, Context Mapping, Ubiquitous Language u.v.m.

Domain-driven Design (DDD) ist einerseits eine Denk- und Arbeitshaltung eines Architekten, andererseits eine Sammlung von Methoden, welche die Bedeutung der Domäne und dessen Modellierung ins Zentrum der Architekturarbeiten stellt. Die Domäne ist das Anwendungsgebiet, resp. der Einsatzbereich der Software, meist also die Fachlichkeit und die Fachlogik eines Geschäftsfelds. Das Domänenmodell ist die Abbildung der Essenz der Domäne mit objektorientierten Konzepten. Bei DDD geht man davon aus, dass der größte Teil der Komplexität einer Software nicht in der technischen Umsetzung liegt, sondern in der Modellierung der Domäne. Domain-driven Design wurde durch das gleichnamige Buch von Eric Evans [1] einem breiteren Publikum bekannt gemacht.

Bevor wir die besagte komplexe Systemlandschaft und deren Systeme robuster und flexibler machen, definieren wir, wie wir Robustheit und Flexibilität im Rahmen dieses Artikels verstehen: Wir definieren Robustheit als die Eigenschaft der Software, auch unter ungünstigen Bedingungen noch zuverlässig zu funktionieren. Dies erreicht man z. B. durch eine Reduktion der Fehlerrate oder auch durch eine gute Strukturierung der Komplexität der Software. Flexibilität ist die Eigenschaft der Software, einfach an geänderte Anforderungen angepasst werden zu können. Dies wäre z. B. die Änderbarkeit oder die Erweiterbarkeit der Software.

DDD auf Ebene Unternehmensarchitektur

Der Unternehmensarchitekt fokussiert sich auf die Applikations- und Systemlandschaft des Unternehmens. Dabei werden Zuständigkeiten der Applikationen geschnitten, Schnittstellen vereinfacht und Technologien harmonisiert. Hierzu verwenden die Unternehmensarchitekten meist ein Framework wie TOGAF [2] oder Zachmann [3], um die Komplexität der Systemlandschaft zu strukturieren und somit beherrschbar zu machen.

DDD geht einen leicht anderen Weg und bietet alternative Methoden an, um z. B. auch implizite Beziehungen und Informationen sichtbar zu machen. Eine mächtige Methode ist die Context Map, mit der man die Kontexte, in denen Domänenmodelle Gültigkeit haben, darstellen kann. Nehmen wir das folgende Beispiel, das uns in diesem Artikel begleiten wird. Die Systemlandschaft der fiktiven Firma Amazine GmbH, eine kleine Onlinebuchhandlung, ist (wie man oft sagt) „historisch gewachsen“: Bevor die Buchhandlung online ging, hatte man nur ein CRM als Kundenverwaltung, eine Lagerverwaltung und eine Buchhaltung. Dann kamen immer mehr Systeme hinzu. Um die Systemlandschaft nun robuster und flexibler zu gestalten, lädt der Unternehmensarchitekt der Amazine einen DDD-Berater ein, ihn tatkräftig dabei zu unterstützen. Als Erstes schafft sich der DDD-Berater einen Überblick mittels der Context-Map-Methode. Dabei befragt er einige Entwickler in Interviews zur Situation. Die Informationen stellt er in einer informalen Karte auf einem Flip-Chart zusammen. In Abbildung 1 wurde die heutige Situation in schwarzer Farbe als Context Map abgebildet.

Abb. 1: Context Map Amazine heute

Die Systeme sind als Kreise eingezeichnet. Auffällig ist das Onlineshopsystem, von dem mehrere Beziehungen ausgehen. In einigen Fällen ist ein „Up“ oder „Down“ erwähnt, dies steht für Upstream und entsprechend Downstream. Hiermit wird die Machthierarchie zwischen den Entwicklungsteams dieser Systeme ausgedrückt, wobei das Team des Systems, das Downstream steht, die Bedingungen des Upstreamsystems akzeptieren muss. Sehen wir uns gleich ein Beispiel in der Abbildung 1 an: Der Onlineshop steht Downstream zur Lagerverwaltung, die eine typische Legacy-Applikation ist. Die Anbindung an dieses System war nicht einfach. Es gibt keine Dokumentation zu den Schnittstellen und das Team der Lagerverwaltung gibt nur spärlich Informationen preis. Nur mit einigem Trial und Error konnte die Schnittstelle erstellt werden. Wenn sich die Schnittstelle ändert, muss der Shop nachziehen. Wünsche an die Schnittstelle wurden bisher nie umgesetzt. Interne Eskalationen haben noch nichts bewirkt. Das Management weiß genau, dass es keine anderen Experten für dieses Legacy-System gibt, und man möchte daher das Team der Lagerverwaltung nicht verärgern. Der Shop steht also klar Downstream zum Lagerverwaltungssystem.

Ein anderes System, das Downstream steht, ist der Produktekatalog. Dieser erhält die Datensätze zu den verfügbaren Büchern der einzelnen Verlage. Als man den Produktekatalog baute, hat man sich stark an Verlag A orientiert und dessen Buchmodell übernommen. Die Daten der anderen Verlage werden in das Modell des Verlags A übernommen. Leider hat Verlag A schon zwei Mal das Modell geändert und jedes Mal musste der Produktekatalog nachziehen und angepasst werden.

Der Produktekatalog steht also Downstream zum System des Verlags A. Bei dieser Beziehung sieht man auch den Bounded Context des Buchmodells, dies ist die gestrichelte Linie, die die Kontextgrenze und somit den Gültigkeitsbereich des Buchmodells angibt. Innerhalb dieses Bereichs verwendet man das gleiche Buchmodell, außerhalb dieses Bereichs kennt man dieses Modell nicht. Ein interessanter Bounded Context wird beim CRM (Kundenverwaltung), beim Shop und dem Empfehlungssystem ersichtlich: Das Modell des Kunden wurde beim Bau des Shops vom CRM-System übernommen. Wieder ist der Shop Downstream zu einem System, zum CRM.

Lesen Sie auch: Interview mit Eberhard Wolff: “Self-contained Systems sind ein Sonderfall von Microservices”

Das Empfehlungssystem ist das Resultat einer Diplomarbeit eines Juniorentwicklers, der heute die meiste Zeit am Shopsystem arbeitet und nebenbei das Empfehlungssystem wartet. Um schnell ein Resultat zu bekommen, hat er das Kundenmodell des Shops übernommen. Immer wenn der Entwickler heute Anpassungen machen muss, muss er aufpassen, keine Nebeneffekte zu erzeugen. Nur gut, dass er auch am Shopsystem arbeitet und dieses System gut genug kennt. Die Kollegen des Kreditkartensystemteams haben einen Adapter gegenüber den Fremdsystemen gebaut, der sie vor Änderungen schützt. In der Sprache des DDD nennt man dies einen Anti-Corruption Layer (ACL), in Abbildung 1 als Rechteck eingezeichnet. Seit sie die ACL haben, ist ihr Kreditkartensystem unangetastet. Klar müssen sie manchmal einen ACL an Änderungen anpassen, aber das interne Modell ihres Systems muss nicht angefasst werden.

Dem aufmerksamen Leser sind wahrscheinlich die Schwächen dieser Systemlandschaft aus der Beschreibung aufgefallen. In Abbildung 2 sind einige Lösungsvorschläge des DDD-Beraters in roter Farbe dargestellt.

Abb. 2: Context Map mit Vorschlag des DDD-Beraters

Das Shopteam hat nun genug vom Lagerverwaltungssystem und baut einen ACL ein. Dadurch schützen sie sich vor zukünftigen Veränderungen der Modelle und der Schnittstellen. In einer späteren Version der Versandapplikation ist eine Schnittstelle zum Lagerverwaltungssystem geplant. Aus diesem Grund baut das Team den ACL zu einem Adaptersystem aus, sodass die Kollegen der Versandapplikation dieses Adaptersystem als eine angenehmere Schnittstelle (z. B. eine sauber umgesetzte REST-Schnittstelle) nutzen können. Der Shop und das Versandsystem sind nun Upstream gegenüber dem Adapter. Außerdem bietet das Adaptersystem nun einen sanften Start, damit mittelfristig die Legacy-Lagerverwaltung abgelöst werden kann.

Um den Shop und die Empfehlungs-Engine robuster bezüglich fremden Modelländerungen zu machen, entscheidet das Shopteam, den Bounded Context des Kundenmodells so zu legen, dass sowohl der Shop als auch die Empfehlungs-Engine in separaten Kontexten liegen und somit beide ihr eigenes Kundenmodell pflegen können. Gemeinsam ist nun nur noch die Kundennummer als Identifikation des Kunden. Der Shop schützt sich dabei mit ACLs. Mit der gleichen Maßnahme wird der Produktekatalog gegenüber Änderungen von externen Systemen geschützt.

Der ACL wird nun so umgesetzt, dass die Systeme auch technisch entkoppelt werden, damit im Fehlerfall des einen Systems das andere System nicht beeinträchtigt wird. Dies kann z. B. mit asynchronem Messaging und expliziten Fehlerbehandlungsroutinen umgesetzt werden. Somit wird die Systemlandschaft noch robuster als z. B. bei eng gekoppelten Systemen.

Sobald ein konsistentes Domänenmodell vorliegt, ist man als Unternehmensarchitekt oft geneigt, verleitet oder gar besessen, dieses Modell über eine ganze Systemlandschaft hinweg konsistent zu halten. Dies ist jedoch kaum möglich oder zumindest nicht kosteneffektiv. Oft ist es sogar kaum möglich, zwischen zwei Teams, die an der gleichen Applikation arbeiten, ein gemeinsames Modell zu pflegen. Schlimmer noch, die Teams denken und glauben, dass sie das gleiche Modell benutzen, in den Details geht das Verständnis jedoch auseinander. Ein berühmtes Beispiel hierzu ist der Verlust der Mars-Climate-Orbiter-Sonde [4]: Weil zwei Teams je Logik gebaut haben, die einen Wert mit unterschiedlichen Einheiten ausgewertet hat, stürzte die Sonde ab. Besser ist es, ganz bewusst einen Bounded Context zu erstellen, in dem das Domänenmodell seine Gültigkeit hat, um dort die Komplexität der Domäne beherrschbar zu machen. Schafft man es, in einer Gruppe innerhalb einer Kontextgrenze oder sogar zwischen Gruppen eine gemeinsame Sprache zu sprechen, nennt Evans dies Ubiquituous Language. Eine Ubiquituous Language liegt vor, wenn alle Beteiligten die Domäne mit den gleichen Wörtern beschreiben und daher alle dasselbe darunter verstehen. Diese einheitliche Sprache ist besonders nützlich, nein gar äußerst wichtig, zwischen den Domänenexperten und des umsetzenden Teams. Besteht keine gemeinsame Sprache, wird die Software viele Fehler aufweisen, unnötige Komplexität beinhalten (wegen widersprüchlichen Implementationen und Nomenklaturen), was die Wartung und die Flexibilität der Software bezüglich Erweiterungen erheblich reduziert.

Lesen Sie auch: Microservices im Experten-Check: Wie groß sollte ein Microservice sein?

Eine große Systemlandschaft hat oft zu viele Systeme und Teile, als dass man alles perfekt modellieren und implementieren könnte. Es macht daher großen Sinn, sich ganz bewusst auf ausgewählte Teile der Systemlandschaft zu konzentrieren und dort mehr zu investieren. Am besten konzentriert man sich auf die so genannte Core Domain, auch Kernfachlichkeit genannt – jenen Aspekt, den die Firma und ihr Business einzigartig macht und den meisten Anwendernutzen stiftet. Meist hat eine Systemlandschaft Systeme und Funktionalitäten, die genauso gut in anderen Firmen auftreten können (z. B. ein DMS, Buchhaltung etc.), diese gehören nicht zur Core-Domain. Die Core-Domain herauszuschälen (Evans spricht von „destillieren“) kann durchaus zu Überraschungen führen. Oft sind sich die Stakeholder nicht genau bewusst, was die Essenz ihres Business genau ausmacht oder zumindest ist man sich darüber nicht ganz einig. In unserem Beispiel befragt der DDD-Berater nun nicht nur Entwickler, sondern auch Domänenexperten, dies sind Personen, die die Fachlichkeit und das Geschäft der Firma Amazine gut kennen, um die Core-Domain zu identifizieren. Wenn man sich Abbildung 1 anschaut, so könnte man schnell zum Schluss kommen, dass der Onlineshop die Core-Domain von Amazine ist. Dem ist jedoch nicht so. Es stellt sich heraus, dass das Empfehlungssystem Amazine von der Konkurrenz abhebt und somit zur Kernkompetenz der Unternehmung geworden ist. Ohne das innovative Empfehlungssystem könnte sich das Unternehmen kaum gegenüber sehr großen Onlinebuchhandlungen behaupten. Nach diesem Ergebnis wurden umgehend mehr Entwicklerressourcen auf dieses wichtige System gesetzt.

Dem Unternehmensarchitekten hilft die Core-Domain-Methode, sich zu fokussieren und Schwerpunkte in der Systemlandschaft zu setzen, z. B. auch für Make-or-Buy-Entscheide: Eine Core-Domain-Funktionalität kann kaum oder nur sehr selten durch Standardsoftware abgedeckt werden, denn sie hebt sich per Definition vom Standard ab und muss daher individuell erstellt werden. Nimmt man trotzdem ein Standardprodukt, kann der Standardsoftwareanbieter dann die Versprechungen nicht halten, da man doch mehr „konfigurieren“ und „anpassen“ muss, als ursprünglich in der Offerte vorgesehen war. Abgesehen davon würde das Unternehmen damit auch die heute notwendige Flexibilität verlieren, wenn die Core-Domain nicht einfach und rasch anpassbar und veränderbar wäre. Das Unternehmen könnte sich dann Veränderungen am Market nicht schnell genug anpassen.

Das Konzept der Core-Domain ist nicht nur für die Unternehmensarchitektur sehr hilfreich. Auch dem Systemarchitekten hilft es, den Fokus auf die wesentlichen und wichtigen Teile der Applikation zu lenken und Schwerpunkte in der Modellierung und Umsetzung zu setzen.

DDD auf Ebene Systemarchitektur

International JavaScript Conference
Hans-Christian Otto

Testing React Applications

by Hans-Christian Otto (Suora GmbH)

Sebastian Witalec

Building a Robo-Army with Angular

by Sebastian Witalec (Progress)

API Summit 2018
Christian Schwendtner

GraphQL – A query language for your API

mit Christian Schwendtner (PROGRAMMIERFABRIK)

Wurden auf der Ebene Unternehmensarchitektur die wesentlichen Bereiche der Fachdomäne identifiziert, gilt es nun, die Umsetzung von einzelnen Systemen optimal zu gestalten.

Zuerst muss man sich als Architekt fragen, wie komplex die Geschäftslogik ist, die das System umzusetzen hat. Für reine Datenerfassungsapplikationen, die bis auf simple Validierungen kaum Geschäftslogik umsetzen, lohnt es sich nicht, den initialen Mehraufwand von DDD zu betreiben. Diese Art von Applikationen werden oft auch CRUD-Applikationen genannt, wobei CRUD für Create Read Update Delete steht. Der Entwicklungsaufwand für CRUD-Applikationen bewegt sich typischerweise im Rahmen von bis zu 3 Mann-Monaten. Um CRUD-Applikationen rasch und effizient umzusetzen, sind Rapid-Application-Development-Frameworks wie z. B. Spring Roo oder Ruby on Rails eine gute Wahl. Falls die Geschäftslogik allerdings richtig Fleisch am Knochen hat, stellen diese Werkzeuge auf lange Sicht nicht die optimale Lösung dar, da die Geschäftslogik zu eng an die einzelnen Masken resp. Datenbanktabellen gekoppelt ist. Die Durchsetzung übergreifender Geschäftslogik wird zunehmend schwierig. In diesen Fällen lohnt es sich als Architekt, nach den Prinzipien von DDD eine saubere Systemarchitektur zu erarbeiten.

Als eine der Hauptaufgaben eines Architekten verstehen wir auf der Ebene Systemarchitektur die Definition von Modulen (Komponenten) eines Systems und deren Abhängigkeiten untereinander. Voraussetzung dafür ist ein ausreichendes Verständnis der umzusetzenden Domäne, bevor die große Masse an Entwicklern am Projekt mitarbeitet. Deshalb muss man auf der Ebene Systemarchitektur tiefer in die Details eintauchen als noch auf der Ebene Unternehmensarchitektur. Da nie alle Details berücksichtigt werden können, braucht man hier schlicht Erfahrung, damit die kritischen Teile identifiziert und gezielt mit den Domänenexperten vertieft werden können. Eine selbst gesetzte Deadline hilft, sich nicht in unwichtigen Details zu verlieren und sich immer wieder anhand der gewonnenen Erkenntnisse auf die wichtigsten Punkte zu konzentrieren. Ziel dieser initialen Modulbildung ist nicht ein perfektes Ergebnis, sondern eine relativ solide Grundlage. Später im Projekt darf man nicht davor zurückschrecken, die Modulbildung anzupassen. Eine „Wird nicht mehr angefasst“-Einstellung ist in der Regel kontraproduktiv, da für benötigte Änderungen einfach in anderen Modulen Workarounds erstellt werden. Dies ist eine Form von so genanntem Technical Debt, also eine Qualitätsschuld, die ein System gegenüber der Zukunft aufweist. Diese Schuld rächt sich irgendwann in Form von verminderter Robustheit und Flexibilität des Systems, womit die Umsetzung von Änderungen immer aufwendiger wird. Automatisierte Tests jeglicher Art (z. B. Unit Tests, Integrationstests etc.) helfen, dass das System auch bei größeren Refactorings immer noch als Ganzes funktioniert. Solange man sich an die Konzepte von DDD zur Modulbildung hält, sind solche Anpassungen auch einfach möglich.

Die wichtigste Grundregel zur Modulbildung bei DDD ist: Die Aufgaben von Modulen und die Abhängigkeiten zwischen Modulen müssen bewusst definiert und umgesetzt werden. Die Module dürfen dabei keine Abhängigkeitszyklen aufweisen, ansonsten können Änderungen an einem Modul rasch ziemlich viele andere Module betreffen. Abbildung 3 zeigt ein stark vereinfachtes Beispiel, wie eine solche Modularisierung für das Shopsystem aussehen könnte. Die Pfeile stellen „verwendete“ Beziehungen dar, z. B. hat das Modul Bestellung eine Abhängigkeit auf das Modul Kunde. Daraus kann man schlussfolgern, dass Änderungen am Modul Kunde auch das Modul Bestellungen betreffen können, umgekehrt jedoch nicht. Die in der Abbildung 3 dargestellten Schichten sind Bestandteil des Layered-Architecture-Konzepts von DDD und sind in Tabelle 1 erklärt.

Abb. 3: Modularisierung Shopsystem

Schicht Beschreibung
UI (User Interface) Interaktion mit dem Benutzer (z. B. eine Web-GUI)
Application Koordiniert Aktionen, die auf der Domäne ausgeführt werden, enthält keine Geschäftslogik, kann z. B. Transaktionen öffnen/schließen und Fremdsysteme aufrufen
Domain Enthält das Domänenmodell, setzt geschäftsrelevante Daten und Geschäftsregeln um
Infrastructure Technische Infrastruktur, die von höheren Schichten verwendet werden kann, z. B. ein Persistenzframework, Messaging-Infrastruktur usw

Tabelle 1: Layered Architecture nach DDD

Parallel zur Modulbildung verfeinert der Architekt das Domänenmodell. Es ist das Herz der Abbildung der Fachlichkeit im System. Abbildung 4 zeigt ein wiederum vereinfachtes Beispiel, wie ein Domänenmodell für unser Shopsystem aussehen könnte. Das Domänenmodell bildet die Ubiquituous Language des Shopsystems ab, ist aber oft zu abstrakt, um von Domänenexperten verstanden zu werden. Das Domänenmodell dient primär als Kommunikationsmittel zwischen den Entwicklern und als Grundlage für das technisch umgesetzte Modell. Da in der Geschäftswelt immer wieder ähnliche Muster in der Fachlichkeit auftauchen, sind Analyse-Patterns, wie z. B. von Fowler in [5] beschrieben, ein wichtiges Werkzeug bei der Definition von Domänenmodellen. Die Bedeutung der verwendeten Stereotypen für Domänenklassen sind in [1] ausführlich erklärt. Aus Platzgründen verzichten wir hier auf eine Erklärung.

Abb. 4: Domänenmodell Shopsystem

Wie wir im ersten Abschnitt bereits erwähnt haben, liegen die größten Herausforderungen bei der Umsetzung eines nicht trivialen Systems oft nicht in der Technik. Zum Abschluss dieses Abschnitts möchten wir nun noch auf das Zusammenspiel zwischen der Systemarchitektur und der Projektorganisation eingehen. Besonders wenn mehrere Entwicklungsteams an demselben System arbeiten, müssen Projektorganisation und Systemarchitektur aufeinander abgestimmt sein.

Die bereits definierten Module können nun einzelnen Entwicklungsteams zugewiesen werden. Ein Entwicklungsteam ist jeweils für alle Aspekte seiner Module verantwortlich. Ganz im Sinne von agilen Teams kümmert es sich interdisziplinär sowohl um das Erheben von Detailanforderungen wie auch um die Implementation. Dies ermöglicht es Entwicklern, mitzudenken und Lösungsvorschläge zu machen. Da die Module nach fachlichen Bereichen geschnitten sind, ist in der Regel auch bereits klar, welche Entwicklungsteams mit welchen Domänenexperten kommunizieren müssen. Dies verhindert, dass die Domänenexperten von verschiedenen Teams zu demselben Thema befragt werden, und diese müssen somit weniger Zeit für das Projekt aufwenden.

Diese Vorgehensweise führt zu klaren Kommunikationswegen und Verantwortungen innerhalb eines Projekts, was den Koordinationsaufwand senkt und somit die Effizienz aller Beteiligten deutlich steigert.

DDD auf Ebene Implementation

In klassischen Systemarchitekturen von Enterprise-Applikationen befindet sich meist die gesamte Geschäftslogik in Serviceklassen, während die Domänenklassen reine Daten-Container darstellen. In einem DDD-System enthalten Domänenklassen neben ihren Daten jedoch auch die dazugehörige Geschäftslogik. Dadurch können Domänenobjekte ihre Geschäftsregeln selbst durchsetzen und ein Domänenobjekt bleibt in sich konsistent. Weitere Aspekte bei der Implementation können unter anderem in [6] nachgelesen werden.

Da zumindest im Java-Umfeld die meisten Frameworks und Bibliotheken nicht auf Domain-Model-Architekturen ausgelegt sind, muss man den einen oder anderen technischen Stolperstein aus dem Weg räumen. Damit wir diese nicht immer wieder von neuem wegräumen müssen, haben wir uns mit mimacom path eine schlanke Sammlung an Guidelines und bereits existierenden Frameworks und Bibliotheken (wie z. B. Spring) zusammengestellt. Wo die eingesetzten Frameworks noch nicht ganz ausreichen, haben wir das Paket durch eigenen Gluecode ergänzt.

Fazit

In diesem Artikel sind aus Platzgründen nur einige ausgewählte Konzepte und Methoden von Domain-driven Design verwendet worden. Beim ersten Kontakt mit DDD empfinden viele Leser die Methoden als „esoterisch“ oder als „zu simpel“. Bei der Anwendung merkt man jedoch rasch, dass sie sehr pragmatisch und effektiv sind und das Lernen von Domänenwissen fördern. Das Lernen ist ein wichtiger Bestandteil des DDD-Denkens, denn man schafft es kaum, beim ersten Kontakt mit der Domäne ein perfektes Modell zu definieren. Durch kontinuierlichen Austausch mit Domänenexperten kann das Modell iterativ verbessert werden. Dadurch wird die Software auch robuster und flexibler. Zudem wird das Hauptziel erreicht, nämlich den Nutzen für den Endbenutzer zu erhöhen. Zu diesem Prozess gehört es auch, dass die Architekten selbst am Keyboard sitzen und die Modelle implementieren, denn zu den Benutzern der Software gehören auch die Entwickler in der Entwicklung und der Wartung.

Es gibt sehr viel Wissen, Bücher und Quellen, wie man robuste und flexible Software bauen kann. Alle Methoden nutzen jedoch herzlich wenig, wenn die Entwickler und Architekten nicht stetig die Disziplin aufbringen, dieses Wissen anzuwenden, Tests zu schreiben, das Modell zu verbessern, an der Kommunikation mit Kollegen zu feilen und die Haltung pflegen, qualitativ hochwertige Arbeit abzuliefern. Und dies auf allen drei Ebenen.

Verwandte Themen:

Geschrieben von
Martin Kernland
Martin Kernland
Martin Kernland arbeitet als Senior Software Architect bei der edorasware ag, einer innovativen Firma im Bereich BPM und Enterprise Work Management. In der Freizeitunterstützt er die Java-Community als Präsident der Java User Group Switzerland (jug.ch).
Adrian Gygax
Adrian Gygax
Adrian Gygaxm arbeitet als Senior Software Engineer und IT-Architekt bei der mimacom ag.DDD konnte er in der Praxis bereits in mehreren Projekten auf allen Architekturebenen anwenden.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: