Domain-driven Design (DDD) erlebt gerade eine Renaissance: Es ist ein vielversprechender Ansatz für die Modularisierung großer Systeme und für Microservices. In der DDD-Praxis ergeben sich aber oft Missverständnisse und Herausforderungen. Dieser Vortrag greift die typischen Herausforderungen auf und zeigt mögliche Lösungen. Dabei geht es beispielsweise um organisatorische Auswirkungen, das Schneiden von Bounded Contexts, die möglichen Beziehungen zwischen Bounded Contexts und auch die Daten-Konsistenz zwischen Bounded Contexts.

Zielpublikum: Technische Projektleiter:innen, Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Software-Entwicklung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Durch meine Architektur-Beratungen sehe ich immer wieder Missverständnisse und Probleme bei der Umsetzung von DDD. Ich würde hier gerne Lösungen dafür diskutieren. Mein Ziel ist es, Zuhörer:innen abzuholen, die sich an einer DDD-Architektur versucht haben. Ihnen möchte ich gerne zeigen, wie man typische Probleme löst.

Selbst grundlegende Begriffe wie Bounded Context oder Upstream / Downstream sind schon nicht einfach zu verstehen. Hinzu kommt, dass diese Konzepte Domänenmodelle, organisatorische Elemente und sprachliche Aspekte (Ubiquituous Language) vermengen. Das führt in der Praxis immer wieder zu Herausforderungen. Neben einem Bewusstsein für das Problem möchte ich aufzeigen, dass man diese Aspekte auch getrennt betrachten kann.

Die Strategic Design Patterns wie Conformist oder Customer / Supplier lösen Situationen unterschiedlich. Dazu möchte ich Orientierung und Auswahlkriterien geben. www.heise.de/hintergrund/Grosse-Systeme-mit-Domain-driven-Design-entwerfen-4684074.html zeigt dazu die wesentlichen Ideen.

Daten-Konsistenz wird meistens als Problem wahrgenommen. Wenn man die Domäne genau genug fachlich untersucht, dann ist die Konsistenz oft kein Problem. Dafür möchte ich Beispiele zeigen.