W-JAX: Domain Driven Design
Zusammenfassung des Vortrages von Arno Haase und Michael Plöd.
Domain Driven Design - Entwurf getrieben von den fachlichen Anforderungen
Warum?
Weil die Fachlichkeit i.d.R. die Aspekte sind, die am längesten stabil bleiben bzw. sich am wenigsten verändern um die sich letztendlich alles dreht. Beispiel: Die Kontonummer eines Kunden hat immer Bestand, egal welche Anwendung darauf zurückgreift. Aus Erfahrung wissen wir auch, dass Daten stabiler als Methoden sind, d.h. Artikel werden seit Jahren immer auf die gleiche Weise abgelegt, egal ob die Zugriffssoftware in COBOL oder Java erstellt wurde.
Was sagen die Vortragenden?
“Einige Dich auf eine Sprache!” - das ist das eigentliche Motto. Domain entspricht hierbei der Fachlichkeit bzw. dem Fachwissen, und zwar explizit nicht der technischen Sicht. Domain Driven heißt hierbei Orientierung am Anwender, also wird alles von der fachlichen Ebene getrieben, nicht von der technischen Umsetzung.
Die Modelle bzw. der Code sollte die Sprache der Fachanwender wiederspiegeln, damit die Anwender direkt mit den Entwicklern sprechen können und ein gemeinsames Verständnis der Begriffe vorhanden ist, auch im Hinblick auf spätere Änderungen und Fluktuationen.
Orientiere Dich in der technischen Umsetzung immer an der Unterstützung der fachlichen Anforderungen, und Deine Codebasis wird stabiler und einfacher sein, sowohl in der Entwicklung als auch in der Wartung, selbst wenn die Anwendung skaliert.
Tipps und Tricks
- Mache die Domain Objects (Geschäftsobjekte) als auch die Business Logic (Geschäftslogik und -prozesse) explizit, bündele sie und denke an die entsprechende Benennung! Factories, Composites, Strategies helfen hier.
- Domain Driven Design ist eine notwendige Voraussetzung für Model-Driven Software Development (MDSD), da sonst keine (stabile) formale Spezifikation möglich ist.
- Domain Driven Design ist hilfreich für Extreme Programming (XP), legt aber mehr Wert auf Dokumentation und kann auch in großen Projekten von großem Nutzen sein.
- Änderungen im Domain Model (sowie in der Domain) sind teuer, lohnen sich aber immer. Verschleppung ist noch teurer, und zwar exponential.
- Partionierung der Domains ist ein gutes Mittel, insbesondere um die Kerndomäne herauszuschälen und die logisch Domänen zu trennen und damit beherrschbar zu machen.
- In großen Projekten muss die Kerndomäne identifiziert werden und kurz und prägnant beschrieben werden, am besten in Form eines “Vision Statements”.