Bei der Entwicklung komplexer Software klafft oft eine Lücke zwischen Umsetzung und Anwendung. Da Entwickler:innen und Architekt:innen aus einem technischen Umfeld heraus auf die fachlichen Probleme schauen, entsteht eine Verständigungsschwierigkeit. Beide Welten haben unterschiedliche Begrifflichkeiten und es ist schwierig, ein gemeinsames Verständnis der Fachdomäne zu erreichen.
Domain-driven Design: Gemeinsames Modell der Fachlichkeit erarbeiten
Domain-driven Design (DDD) setzt an diesem Punkt an. Basierend auf einem iterativen Vorgehen wird ein Modell der Fachlichkeit entwickelt, mit dem sowohl Entwickler:innen als auch Fachexpert:innen etwas anfangen können. Ein entscheidender Aspekt ist hier das von Eric Evans als „Deep Insight“ bezeichnete tiefe Verständnis der Fachlichkeit, das oft zu einer wesentlich besseren Softwarelösung führt.
Praxisorientiert: Fallbeispiel im Fokus
Anhand eines durchgängigen Fallbeispiels durchlaufen wir gemeinsam den DDD-Prozess, um die Domäne besser zu verstehen und daraus schließlich zu einem Modell zu kommen, das für Fachexpert:innen und Entwickler:innen gleichermaßen hilfreich ist. Dabei kommen Explorationstechniken wie Event Storming sowie DDD-Patterns und -Bausteine im Rahmen der Modellierung zum Einsatz.
Umsetzung in der Architektur
Wir erarbeiten uns sogenannte „Bounded Contexts“, die voneinander unabhängige Subdomänen mit eigener Fachsprache („Ubiquitous Language“) darstellen. Sie eignen sich ideal für eine verteilte Softwarearchitektur wie beispielsweise Microservices, bei der jedem Bounded Context ein eigenes Entwicklerteam zugeordnet ist.
Exemplarisch zeigen wir, wie man vom Modell zur Implementierung gelangt.
