Softwareprojekte scheitern oft nicht an der Technik, sondern an interdisziplinärer Kommunikation, wenn es zwischen Entwicklern und Fachleuten Verständnisprobleme gibt. Sie arbeiten mit unterschiedlichen Terminologien und sprechen somit unterschiedliche Sprachen. Hilfreich ist ein einheitliches und standardisiertes Vorgehen, das Entwickler und Fachexperten integriert. Domain-driven Design (DDD) verfolgt dieses Ziel.

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

Wir zeigen, warum man Collaborative Modeling (CoMo) braucht, und beschreiben den gemeinsamen Kern verschiedener CoMo-Methoden. Vier solche Methoden stellen wir vor und geben Handlungsanleitungen: Welches Problem lässt sich mit welcher Methode anpacken und wie kombiniere ich Methoden sinnvoll in einem agilen Entwicklungsprozess?

Legacy-Code treibt die Entwicklungskosten in die Höhe und führt dazu, dass wir diese alten Softwaresysteme nicht mehr gerne anfassen. Ist das unvermeidbar? Können wir etwas tun? Mit Domain-driven Design (DDD) haben wir ein Werkzeug zur Hand, um Legacy-Code Schritt für Schritt wieder in den Bereich beherrschbarer Wartungskosten zu bringen.

Weder Domain-driven Design (DDD) noch Microservices sind konzeptionell neu. Trotzdem erfahren beide Themen seit einigen Jahren zunehmend mehr Zuspruch und werden immer häufiger auch gemeinsam genannt. Woran liegt das?

Im Artikel von Carola Lilienthal und Michael Plöd [1] wurde gezeigt, wie man eine Domäne in mehrere Bounded Contexts aufteilt. Dabei erhalten wir statt einem großen, schwer verständlichen und schwer wartbaren Domänenmodell nun mehrere, besser handhabbare Domänenmodelle. In diesem Teil der Serie schauen wir darauf, wie man das einzelne Domänenmodell konkret implementieren kann.

Ein Element, das in der gesamten Domain-driven-Design-Literatur querschnittlich präsent ist, ist die Ubiquitous Language, die allgegenwärtige Sprache. Allgegenwärtig bezieht sich darauf, dass es sich hierbei um eine Sprache handelt, die von Softwareentwickler*innen und Fachexpert*innen gemeinsam gesprochen wird. Diese Sprache soll dann auch die Basis für die Entwicklung des Softwaremodells sein. Im Rahmen dieses Artikels gehen wir erst auf die Motivation für die Etablierung einer Ubiquitous Language ein, bevor schließlich das Potenzial und die Möglichkeiten für die Arbeit mit einer solchen Sprache vorgestellt werden. Weiterhin werden noch kurz die Vorgehensweisen zur Herleitung einer Ubiquitous Language erläutert.

Domain-driven Design (DDD) ist eine alte Technik, aber gerade voll im Trend. Worum geht es bei DDD und ist der Hype berechtigt?

Die Geburtsstunde des Domain-driven Design liegt im Jahr 2003. Eric Evans Buch „Domain-Driven Design: Tackling Complexity in the Heart of Software“ war ein Meilenstein und wird heute noch vielfach rezipiert. Entscheidend zur Verbreitung von DDD hat zudem Vaughn Vernons Werk „Implementing Domain-Driven Design“ beigetragen. Wir haben uns mit Vaughn über die Motivation und Kernideen hinter DDD sowie ihr Verhältnis zu Microservices und reaktiven Architekturen unterhalten.

Fassaden bereiten die Möglichkeiten einer Domäne für einzelne Anwendungsfälle auf und verbergen Details der Zustandsverwaltung.

Event Storming ist im Domain-driven Design eine gute Methode, ein gemeinschaftliches Verständnis aller Projektbeteiligter bezüglich der Anwendungsdomäne zu erlangen und dabei ein Prozessmodell zu erstellen. Oft wird dabei aber außer Acht gelassen, dass die dabei entwickelten Informationen nur mit wenig Aufwand direkt in automatisierbare Testfälle transformiert werden können. Daher soll hier die Frage beantwortet werden, wie die verschiedenen Modellierungspattern des Event Stormings in sinnhafte Behavior-driven-Design-Testfälle umgesetzt werden können.

Nur wenn wir die Landschaft um uns herum kennen, können wir unsere Route durch unwegsames Gelände sinnvoll planen. Landkarten (Maps) helfen uns dabei, Hindernisse gezielt zu umgehen, auf dem Weg befindliche Chancen zu erkennen und günstige Ausgangspositionen für kommende Etappen zu finden. Zeichnen wir also eine Karte!

Obgleich das Zielbild sowohl ein Monolith als auch eine Microservices-Architektur sein kann – das Axon Framework offeriert einen leichtgewichtigen Ansatz zur Implementierung Event-basierter Anwendungen. Dabei stützt sich das Framework auf gängige Muster aus dem Domain-driven Design (DDD) [1] und begünstigt die Umsetzung einer Anwendung nach dem Architekturprinzip Command Query Responsibility Segregation (CQRS) [2] und der Persistenzstrategie Event Sourcing [3]. Durch diese Flexibilität und die Tatsache, dass das Axon Framework bestens mit dem Spring Framework integriert ist und damit ein quasistandardisiertes Programmiermodell unterstützt, ist es für den modernen Java-Entwickler einen Blick wert.

Weder Domain-driven Design (DDD) noch Microservices sind konzeptionell neu. Trotzdem erfahren beide Themen seit einigen Jahren zunehmend mehr Zuspruch und werden immer häufiger auch gemeinsam genannt. Woran liegt das?