Domain Driven Design
Moderne Modellierung komplexer objektorientierter Software
Nicht selten wird Software so entwickelt, dass Prozesse nur ungenügend abgedeckt werden. Fachprozesse werden dann den Mängeln einer Software angepasst. Eine gemeinsame Sprache hilft solche Diskrepanzen zu verhindern, denn Software muss die Sprache der Menschen sprechen und nicht Menschen die Sprache der Software lernen. Domain Driven Design schafft genau dafür die Grundlage, indem eine gemeinsame Syntax – in der Regel die der Fachabteilung – als „Muttersprache“ für alle Softwareentwicklungsprozesse etabliert wird. Das führt dazu, dass Software nicht mehr in „Thread“ oder „lock“ durchdacht wird, sondern in „Person“ oder „Abbuchung“. Fachabteilungen können so, weil sie die Software verstehen, viel früher Feedback geben und diese so ausrichten, dass sie unterstützt und nicht zum Hindernis wird.
Grundlagen
Bei Domain Driven Design arbeiten Entwicklung und Fachabteilung zusammen, nicht gegeneinander. Es ist wichtig, dass die verwendeten Begrifflichkeiten wie „Domänenentität“ untereinander klar sind, damit die gemeinsame Arbeit an Domänen zu einer kontinuierlichen und nicht nur sporadischen Aufgabe wird.
- Was „Stärkung der Domäne“ heißt
- CRUD-basierte Persistenzmodelle
- Anemic Domains
- Typische Smells
- SOLID, DRY, YAGNI als Grundlagen für „saubere“ Domänen
- Bausteine für ein robustes Klassenmodell
- Testbarkeit
- Praktische Übungen: Klassenmodellierung
Strategisches Design
Die Entwicklung und kontinuierliche Erweiterung von Geschäftsanwendungen wird zunehmend komplexer: Immer mehr Anwender unterschiedlicher Fachbereiche greifen auf eine gemeinsame Datenbasis zu. Neben klassischen Desktopoberflächen müssen Funktionalitäten zunehmend über webbasierte Schnittstellen und auf mobilen Endgeräten zur Verfügung stehen.
Neben der klassischen Schichtenarchitektur gibt es zur Strukturierung der fachlichen und technischen Aspekte bewährte Alternativen. Durch Anwendung der Techniken des Domain Driven Design lassen sich komplexe, monolithische Anforderungsblöcke in voneinander abgegrenzte Module überführen. Durch gezielte Fragen können solche Anwendungsteile relativ einfach identifiziert werden.
Es ist damit möglich, das eigentliche Domänenmodell und seine Prozesse von der Persistenzschicht und der Benutzerschnittstelle zu entkoppeln. So kann sich die Geschäftslogik ganz unabhängig von Infrastruktur, Datenmodell und Darstellungsvariante weiterentwickeln.
- Was ein Domänenmodell ist
- Bounded Contexts vs. Enterprise Models
- Wann und unter welchen Umständen Domain Driven Design überhaupt Sinn macht
- Hexagonale Architektur vs. Layer-Modell
- Verhalten vs. Struktur
- User Intent: Was der Benutzer beabsichtigt
Übungen
Die Fachabteilungen formulieren ihre Anforderungen neu und die Entwicklung wendet die neuen Erfahrungen mit dem Domain Driven Design dafür an.
- Praktische Übungen: Domänenmodellierung
- Gemeinsames Arbeiten an Ihrem Modell (idealerweise nehmen Entwicklung und Fachabteilung teil)
- Reflektion / Retrospektive über die bisherige Kommunikation im Team bzw. aktuelle Projekte und wo Änderungen notwendig sind