#DDD

DDD: taktisches Design – Architektur innerhalb eines Bounded Context

Im Artikel von Carola Lilienthal und Michael Plöd 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.

Gemeinsam mehr erreichen

Die Verbreitung der Akronyme CQRS und DDD nimmt seit einigen Jahren stetig zu: Vor allem im Kontext von Microservices begegnet man den beiden Konzepten immer häufiger. Was steckt dahinter?

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.

Event Storming aus der Sicht eines Testers

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.

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.

Neu am Kiosk: Entwickler Magazin Spezial Vol. 24: Domain Driven Design

Das neue Entwickler Magazin Spezial Vol. 24 Domain Driven Design ist ab sofort am Kiosk erhältlich. Mit Beiträgen zu den Grundlagen und zum Entwurf einer funktionalen Softwarearchitektur, zu Legacy mit DDD verbessern sowie Strategic Design uvm., bietet die neue Ausgabe viele spannende Artikel rund um das Thema Domain-driven Design.

Domain-driven Design in Angular? Taktisches DDD und Monorepos

Taktisches DDD hilft bei der Beherrschung der steigenden Komplexität in Single Page Applications (SPAs) und harmoniert noch dazu gut mit den in der Angular-Welt anzutreffenden Gepflogenheiten. Wie lassen sich bewährte Architekturkonzepte wie z. B. DDD nun in Verbindung mit modernen JavaScript-Businessanwendungen nutzen?

Funktional vs. objektorientiert: Warum sich funktionale Programmierung besser für Domain-driven Design eignet

Funktionale Programmierung hat wesentliche Auswirkungen auf die Software-Architektur, sagen Nicole Rauch und Dr. Michael Sperber im Interview vom Software Architecture Summit. Wir haben gefragt, was funktionale Architektur von objektorientierter Architektur unterscheidet, warum funktionale Programmierung sich hervorragend für Domain-driven Design eignet und wie man sich dem Thema in der Praxis am besten nähert.

Domain-driven Design: Warum jetzt die Zeit für DDD gekommen ist

Domain-driven Design erlebt unter Software-Architekten gerade einen großen Zuspruch. Im Interview erklärt Mathias Bohlen, Experte für effektive Produktentwicklung und Trainer des DDD Camp, warum das so ist, was taktisches DDD bedeutet und wie man die ersten Schritte in Richtung Domain-driven Design unternehmen kann.

X
- Gib Deinen Standort ein -
- or -