DDD

Ubiquitous Language: Warum ist Sprache so wichtig?

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.

Vaughn Vernon über DDD, Microservices und reaktive Programmierung

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.

Vom Monolith über modulare Architekturen zu Microservices mit DDD

In jedem Unternehmen gibt es große Softwaresysteme, die über viele Jahre weiterentwickelt wurden und deren Wartung Jahr für Jahr immer zäher und teurer wird. Vor dem Hintergrund neuer Architekturparadigmen wie Microservices sollen diese Systeme nun modern, skalierbar und flexibel werden. Dabei ist die Hoffnung, dass man sich der großen, schwerfälligen Monolithen entledigen kann, indem man sie in kleinere, besser zu beherrschende Microservices zerlegt.

Event-basiert und evolvierbar: Appentwicklung mit Axon Stack

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.

DDD: Taktisches Design – Architektur innerhalb eines Bounded Context

In Teil 2 dieser Serie [1] haben uns Carola Lilienthal und Michael Plöd 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.

DDD-Artikelserie: Ubiquitous Language – Warum ist Sprache so wichtig?

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.

Von Service-orientierten Architekturen (SOA) zu DDD und Microservices

Ein Umbau von Monolithen hin zu Microservices ist aufwendig und kann, falsch eingeleitet, zu einem schlechteren Ergebnis führen als es die ursprüngliche Architektur einmal war. Auf Basis der Erfahrungen aus Kundenprojekten der letzten Jahre zeigt Carola Lilienthal in ihrer Session von der W-JAX 2018 , wie man sinnvolle von unsinnigen Maßnahmen trennt und stellt pragmatische Lösungen vor.

Req4Arcs: Anforderungen mit DDD klären

In der vorigen Folge haben Sie gesehen, wie wir Überblick über die wesentlichen funktionalen Anforderungen bekommen können – nämlich indem wir von groben Zielen ausgehend die Granularität von Anforderungen verfeinern und dabei Geschäftsprozesse und Ende-zu-Ende-Abläufe (Use Cases oder User Stories) untersuchen. In dieser Folge möchten wir das Thema Domain-driven Design (DDD) aufgreifen und auf dessen Ansätze in puncto „Requirements“ eingehen.