Domain-driven Design (DDD): Back to the roots

Wie man dem User-Programmer-Gap entkommen kann

Ein Fachbeitrag von Phillip Conrad, Segment Manager Finance & Public

Warum Domain-driven Design (DDD) für Sie relevant ist? Fachliche Anforderungen korrekt zu erfassen ist eine Herausforderung. Stets gilt es, sie in ein technisches Lösungskonzept zu überführen und dieses Konzept mit dem Kunden möglichst früh zu validieren. Denn je eher Falschinterpretationen aufgedeckt werden, desto einfacher – und günstiger – sind ihre Korrekturen. Hauptziel ist dabei, die Lücke zwischen Domänen-, Problem- und technischem Detailwissen zu schließen und das bekannte User Programmer Gap möglichst kleinzuhalten.

SMF hat dazu in Anlehnung an bewährte Best Practices ein Vorgehensmodell zur praktischen Anwendung von Aspekten aus dem Requirements Engineering sowie Domain-driven Design (DDD) entwickelt. Mit diesem Modell soll die Rückkopplung zwischen späteren Anwender*innen und Entwickler*innen– über die eigentliche Anforderungserhebung hinaus – verbessert werden.

Domain-driven Design (DDD)

Was ist Domain-driven Design (DDD)?

Voraussetzungen für eine gelungene Anforderungserhebung
Die Anwendungsszenarien sind bei fachlichen Ansprechpersonen häufig verstrickt und weniger strukturiert, sodass je nach Qualität der abrufbaren Informationen ein längerer Prozess resultieren kann. Nur durch eine regelmäßige und interdisziplinäre Kommunikation kann ein valides Lösungskonzept entstehen. Agile Vorgehensweisen helfen an dieser Stelle ebenfalls, komplex-chaotische Situationen zu beherrschen (vgl. Cynefin-Unterscheidung) und ein inkrementelles Vorgehen zu ermöglichen.

Unabhängig vom Projektvorgehensmodell (agil oder klassisch) wird stets ein Ansatz benötigt, welcher die Anforderungen strukturiert erfasst und fachlich korrekt in Form von Software abbildet.

Geliefert wird letztendlich auf der Entwicklungsebene: Entsprechend ist es sicherzustellen, dass so viele Missverständnisse oder Widersprüche wie möglich im Vorfeld identifiziert und geklärt werden, damit keine falschen Fakten per Quellcode geschaffen und Korrekturschleifen reduziert werden können. Abzustimmen sind auch die geltenden Rahmenbedingungen, in denen eine Software eingesetzt wird, um ein unnötig teures Over-Engineering oder auch eine Unterschätzung der nicht-funktionalen Anforderungen zu vermeiden.

Welche Vorteile bringt Domain-driven Design?

Nach dem Domain-driven Design (DDD)-Paradigma ist die Lösung dieser Problemstellung gleichzeitig so simpel wie auch komplex: „Gutes Zuhören und das Finden einer gemeinsamen Sprache („Ubiquitous Language“ nach Evans). Ist ein Entwickler oder eine Entwicklerin bereits längere Zeit in einer Domäne tätig, können sie diese Lücke selbst schließen und Rückfragen aus der Fachabteilung kompetent begegnen.

Alternativ können zur Minderung dieser Lücke Business-Analysten einbezogen werden, welche in beiden Welten zuhause sind und entsprechend als Bindeglied „übersetzen“.

Damit wäre in beiden Fällen die Ubiquitous Language gefunden. Hinausgehend über die Anforderungserhebung und der gemeinsamen Sprache ist es uns ein Anliegen, mit nachfolgendem Phasenmodell die Rückkopplung zwischen dem technischen Lösungskonzepten und den Anforderungen der späteren Nutzern kontinuierlich aufrecht zu halten.

Fünf Phasen für das „optimale“ Vorgehen

1. Verstehen, ausrichten und definieren

In dieser Phase richten wir unseren Fokus auf das Geschäftsmodell, die Bedürfnisse der Nutzer sowie die kurz-, mittel- und langfristigen Ziele des Projektes. Jede Entscheidung, die wir in Bezug auf die Architektur, den Code oder die Organisation treffen, hat geschäftliche und benutzerbezogene Konsequenzen. Für die spätere Gesamtlösung sollen unsere Entscheidungen möglichst die optimalen Auswirkungen erzielen.

In dieser Phase gilt es, im gesamten Team ein gemeinsames Verständnis über Vorgehensweisen wie das Event-Storming oder Userstory-Mapping für die Domäne aufzubauen und somit später die richtigen Designentscheidungen treffen zu können. Spätere Entwickler*innen und Nutzer*innen sind entweder beteiligt oder es erfolgt eine entsprechend aufmerksame Dokumentation, um sowohl das Domänenwissen als auch Designentscheidungen für spätere Beteiligte zu archivieren.

Zielführend ist an dieser Stelle die Definition eines minimal überlebensfähigen Produkts (MVP): Was sind Muss-Anforderungen? Was sind zukünftige Erweiterungen? Ist eventuell eine agile Vorgehensweise mit frühen Lieferinkrementen anwendbar? (vgl. MoSCoW-Priorisierung).

2. Teile und herrsche

Das Hauptziel dieser Phase ist die Identifizierung von loser Kopplung und hoher Kohäsion innerhalb der Domäne, die sich auf die Softwarearchitektur und Teamstruktur übertragen lässt. Es ist ein Domain-driven Design (DDD)-Paradigma, nicht nur große Domänen in kleine Teile zu zerlegen, sondern auch die Wechselwirkungen zwischen diesen Teilen sorgfältig zu gestalten, um unerwünschte Kopplungen und Komplexität zu minimieren. In der späteren Entwicklungsphase kann jede Subdomäne als ein Service getrennt realisiert werden, welcher wiederum aus mehreren Microservices oder Modulen bestehen kann.

Durch das Zerlegen der Gesamtdomäne in einzelne Subdomänen lassen sich große Projekte entsprechend kontrolliert realisieren. Dabei wird die Problemdomäne zerlegt, um die kognitive Belastung zu reduzieren. So kann weitestgehend unabhängig über einzelne Teile der Domäne weiter entschieden werden. Prozesse zur weiteren Feinspezifikation oder agilen Umsetzung können somit autonom und parallel durchgeführt werden.

3. Architekturentwurf

In dieser Phase wird auf der Architekturebene definiert, wie die einzelnen Subdomänen verbunden werden und miteinander interagieren. Daraus leiten sich die Laufzeitsicht und Kommunikationsarchitektur ab. Eine lose gekoppelte Gesamtarchitektur soll entstehen, in der einzelne Komponenten kombiniert werden, um die entsprechenden End-to-End-Geschäftsanwendungsfälle zu erfüllen. Das ursprüngliche Design wird durch das Betrachten konkreter Anwendungsfälle infrage gestellt, um verborgene Komplexitäten aufzudecken und entsprechend nachzubessern.

An dieser Stelle kommen UML-Komponentendiagramme und UML-Verteilungsdiagramme zum Einsatz. Für die Modellierung des Domänennachrichtenflusses kann ein UML-Sequenzdiagramm oder die BPMN eingesetzt werden. Diese grafischen Modellierungstechniken tragen zur Dokumentation und zum besseren Verständnis aller Beteiligten bei. Insbesondere BPMN-Diagramme können i. d. R. sehr gut von der Fachabteilung verstanden und validiert werden.

4. Strategie und Organisation

Nun gilt es, eine bessere Vorstellung davon zu gewinnen, wie viel „Qualität“ und „Genauigkeit“ jeder Teil des Systems benötigt. Dafür werden Subdomänen strategisch geordnet, um Kerndomänen zu identifizieren, d. h. die Teile der Domäne, welche das größte Potenzial für einen geschäftlichen Erfolg oder generell eine höhere strategische Bedeutung haben.

Da Zeit und Ressourcen begrenzt sind, ist es effektiv, sich auf die Teile der Domäne zu konzentrieren, die eine optimale geschäftliche Wirkung erzielen. Aus diesen Erkenntnissen können ebenfalls verschiedene qualifizierte Entscheidungen wie z. B. bei einer „Build-vs-Buy-vs-Outsourcing“-Fragestellung oder im einfachsten Fall eine Umsetzungsreihenfolge gemäß der Priorität hergeleitet werden.

Für die spätere Umsetzungsphase muss nun ein Arbeitsmodell für möglichst autonome Teams hergeleitet werden. Dies erhöht die Liefergeschwindigkeit und ermöglicht einen optimalen Parallelisierungsgrad im Gesamtprojekt. So lassen sich die richtigen Teamgrößen und etwaige Busfaktoren bestimmen.

Eine weitere Zielsetzung dieser Phase ist die Definition von Teamgrenzen bzw. Team-verantwortlichkeiten. Die jeweiligen Liefergegenstände eines Teams, z. B. mehrere Microservices innerhalb einer Subdomäne, können so definiert und später geplant werden. Eine Rückkopplung auf das Gesamtdesign ist an dieser Stelle erwünscht und kann einen positiven Einfluss auf die Effizienz des Projekts haben.

5. Umsetzungsvorgaben

In dieser Phase definieren wir die notwendigen Artefakte, um möglichst sicherzustellen, dass keine Denaturierung der Architektur bei der Umsetzung stattfindet. Durch das Ausrichten des Codes an der Domäne sollen sich die Quellcode-Artefakte später ändern und warten lassen. Zudem ist eine wiederkehrende Rückkopplung mit den fachlichen Anforderungen sicherzustellen, sodass stets nach möglichen Missverständnissen aufgrund des User-Programmer-Gaps gesucht wird.

Wie wir Domain-driven Design anwenden

Durch die Modellierung des Fachkonzepts, beispielsweise über UML-Klassendiagramme, haben die aktuellen und späteren Entwicklerinnen und Entwickler sowohl die Möglichkeit, sich über die Architektur auf Komponenten- und Klassenebene zu informieren als auch sich die fachliche Domäne schnell zu erschließen. Es entsteht eine fortlaufend gepflegte, technische Dokumentation.

Durch die Definition von konstruktiven Qualitätsmanagementvorgaben kann eine gleichbleibende Qualität ermöglicht werden, z. B. über Richtlinien, Standards und Checklisten sowie durch die Etablierung von automatisierten CI/CD-Strecken. Dabei helfen analytische Qualitätsvorgaben wie manuelle Code-Reviews zwischen den Entwickler*innen sowie besonders hervorzuhebende, frühe Show-and-Tells mit den Stakeholdern. So wird die Erwartungshaltung aller Projektbeteiligten eingehalten.

Fazit

Softwareprojekte sind erfolgreich, wenn sie die Anforderungen und Bedürfnisse ihrer Nutzer*innen korrekt abbilden und hierdurch die anvisierten Mehrwerte erzielen. Fehlinterpretierte Anforderungen oder überzogene Softwaredesigns sind unnötige Gründe, warum Projekte scheitern können.

SMF hat hierzu den vorgestellten Prozess zur praktischen Anwendung der DDD-Aspekte entwickelt. Mit den Ansätzen nach DDD erhalten wir nichts grundlegend Neues, aber eine sinnstifte Kombination aus altbewährten Vorgehensweisen der objektorientierten Analyse (OOA) sowie des Requirements Engineerings. Dabei werden diese Methoden verfeinert und ergänzend eingesetzt.

Oberstes Ziel ist der Aufbau eines gemeinsamen Verständnisses sowie die Übernahme fachlicher Zusammenhänge in das Softwaredesign hinein. Strukturiertes Vorgehen und fortwährendes Mapping auf Kundenanforderungen helfen bei der Sicherstellung der korrekten Abbildung aller Anforderungen. Die Wartbarkeit, insbesondere durch ursprünglich nicht Beteiligte, kann durch die Komponenten/Subdomänen-Bildung zusätzlich verbessert werden.

Diese Methoden zur Durchführung von System- bzw. Anforderungsanalysen haben sich bereits vor der Publikation von Eric Evans als bewährt herausgestellt und wurden in der Praxis tagtäglich ohne den bewussten Einsatz von Domain-driven Design (DDD)-Mitteln eingesetzt. Aber gerade in neuen Kunden-Lieferantenbeziehungen kann der explizitere Einsatz eines solchen Ansatzes helfen.

Wir bevorzugen hierbei ein pragmatisches Vorgehen mit Fokus auf den vorliegenden Kernaspekten und passen dies je nach Kundensituation individuell an. Hierdurch gelingt es, ausgehend von den Anforderungen, die richtigen Designentscheidungen zu treffen und diese bis zur Codierungsebene aufrechtzuhalten.

Gerne unterstützen wir auch Ihre digitale Transformation und bilden Ihre fachlichen Anforderungen an qualitative Softwarelösungen ab. Ich freue mich auf Ihren Anruf.

Die SMF GmbH hat sich in den letzten Jahren eine starke Lösungskompetenz im Bereich der Digitalen Transformation im Public-Sektor erarbeitet. Erfolgreich durchgeführte Projekte kommen aus dem Energiehandel, dem Verlagswesen, im Rahmen von IoT-Plattformen und aus dem öffentlichen Sektor mit mehr als einer halben Million Nutzern und über 60 angebunden Services.

Phillip Conrad
Experte für Transformationen bei SMF

Segment Manager
Finance & Public
+49 231 9644-422
p.conrad@smf.de

Glossar

BPMN

Die „Business Process Model and Notation“ ist ein Standard zur grafischen Modellierung von Geschäftsprozessen.

Build-vs-Buy-vs-Outsourcing

Häufige Entscheidungsherausforderung bei Neuprojekten zwischen drei Lieferstrategien: eine Lösung selbst entwickeln, eine fertige Lösung einkaufen (und anpassen) oder eine Entwicklung extern auslagern.

Cynefin-Unterscheidung
Das Cynefin-Framework ist ein Modell zur Einordnung von Problemkontexten und kann zur Entscheidungsfindung bzgl. Projektvorgehensmodellen sowie zur Strategieplanung eingesetzt werden.

Domain-driven Design (DDD)

Konzept zur Verbesserung der Abbildung von fachlichen Anforderungen auf die Lösungsebene

MoSCoW-Priorisierung

Methode zur Priorisierung nach: Must, Should, Cloud und Won’t have

MVP

Ein „Minimum Viable Product“ ist die erste, minimal funktionsfähige Iteration einer Lösungsentwicklung. Es stellt wortwörtlich ein „minimal brauchbares oder existenzfähiges Produkt“ dar.

„Ubiquitous Language“ nach Evans

Gemeinsame Sprache zwischen Entwickler*innen und Nutzer*innen

User Programmer Gap

Wissenslücke zwischen Nutzer*innen und Entwickler*innen

Requirements-Engineering

Umfasst das Ermitteln, Analysieren, Spezifizieren und Validieren aller Eigenschaften und Rahmenbedingungen eines Softwaresystems

Show-and-Tell

Präsentation eines aktuellen Entwicklungsstands

UML-Komponentendiagramme

Das Komponentendiagramm ist ein Strukturdiagramm zur Visualisierung von Komponenten und dessen Abhängigkeiten. Hierdurch kann eine Vogelperspektive auf die Makroarchitektur eines Softwaresystems eingenommen werden.

UML-Sequenzdiagramm

Ein Sequenzdiagramm ist ein Verhaltensdiagramm, welches die Lebenslinie und die Interaktion zwischen Objekten grafisch darstellt.

UML-Verteilungsdiagramme

Ein UML-Verteilungsdiagramm ist ein Strukturdiagramm zur Visualisierung der Verteilung von Softwarekomponenten auf deployment-nahe Betriebsmittel.