Das „wichtigste“ – und in der Praxis oft produktivste – Axiom von DDD ist dabei die von Alberto Brandolini mit „Es ist das (Miss-)Verstehen der Entwickler, nicht das Wissen der Domänenexperten, das produktiv geht“ zusammengefasste Feststellung, dass Fachwissen in Entwicklerhand für das erfolgreiche Durchlaufen eines Projekts vernünftig ist. Daraus folgt der Inhalt der ersten vier Kapitel. DDD führt im Bereich des Domain-Verständnisses Denk-Patterns ein, die mit dem Fachthema nicht vertrauten Entwicklern anhand einer „formalisierten Ontologie“ die Einarbeitung in das jeweilige Fachthema erleichtern. Wer mit Themen wie Bounded Context oder der „Interaktion“ zwischen den einzelnen Kontexten oder Domänen Probleme hat, wird anhand Dutzender praktischer Beispiele kompetent in die Welt des DDD-schen Denkens eingeführt. Obwohl der erste Teil des Lehrbuchs noch ohne Codebeispiele auskommt, bemerkt man schon hier ein durchaus hohes fachliches Niveau. Am Ende jedes Kapitels befindet sich ein kleiner Multiple-Choice-Test, der eine sofortige Verständnisprüfung ermöglicht – im Interesse der Offline-Nutzbarkeit des Lehrbuchs findet sich am Ende des Werks außerdem noch ein Appendix, der die korrekten Antworten samt kurzen Erklärungen bereitstellt.
Und jetzt, mit Code!
Lehrbücher zur Softwarearchitektur leiden nur allzu oft darunter, dass der Leser nur wenige praktische Beispiele an die Hand bekommt. „Einführung in Domain-Driven Design“ beginnt im zweiten Teil – er läuft unter dem Signet taktisches Design – damit, „wie“ man Ubiquitous Language und Bounded Contexts miteinander verknüpft. Wie im Fall der meisten Patterns-Sammlungen steht der Entwickler an dieser Stelle wie der berühmte Ochs vor dem Scheunentor, und ist so klug als wie zuvor. Der dritte Teil des Lehrbuchs betrachtet deshalb Probleme der Systemtechnik und gibt dem geneigten Leser Werkzeug in die Hand, um aus dem Fundus der DDD-Design-Patterns das zur vorliegenden Aufgabe am „besten“ passende Werkzeug auszuwählen. Der einst mit Flussdiagramm und Co. aufgewachsene Rezensent empfand am vorliegenden Lehrbuch besonders sympathisch, dass sich Khononov nicht auf eine textuelle Beschreibung beschränkt, sondern Flowcharts zur Entscheidungsfindung einbindet. Sehr nett ist auch die Beschreibung des im DDD-Bereich häufig verwendeten Event Storming: Ein normalerweise in Präsenz abzuhaltendes Meeting, das die diversen für die DDD-Prozesse notwendigen Informationen zu „heben“ sucht. Nett ist in diesem Zusammenhang, dass Khononov, wenn auch eher kurz, Hinweise dazu gibt, wie man (in Zeiten von COVID-19-Pandemie und Co. nützlich) Event Storming-Meetings in Telepräsenz abhält. Zur „Abrundung“ dieses Teils präsentiert das Werk Methoden, wie man DDD-Vorgehensweisen in Brownfield-Projekten anwendet: Ein Greenfield-Design, das von nun an auf Basis von DDD entsteht, dürfte man in der Praxis nämlich nur höchst selten antreffen.
DDD ist keine Insel!
Khononov beschränkt sich nicht darauf, die „reine Lehre“ des DDD zu präsentieren. Der vierte und letzte Teil des Buchs zeigt Schnittstellen zwischen DDD und Microservices und geht auf eventgetriebene Architekturen und verschiedene Datenmodelle ein. Zu guter Letzt findet der Leser dann noch eine kurze Fallstudie, die eine „praktische“ Implementierung von DDD-getriebenen Entwicklungsprozessen in einem Start-up illustriert.
DDD für Praktiker!
Wer bisher der Meinung war, Domain-Driven Design ist eine Technologie, die ausschließlich im Elfenbeinturm existiert, sollte dieser Einführung eine Chance geben. Das Lehrbuch zeigt die „praktischen Vorteile“ der Arbeit mit DDD, ohne dabei übermäßig mit Theorie zu nerven. In Bezug auf die Übersetzung ins Deutsche – Khononov schrieb ja in Englisch – gibt es keinen Anlass zur Kritik: Das Buch liest sich flüssig und nervt nicht mit den sonst oft lästigen „Anglizismen“.
- title
- Einführung in Domain-Driven Design: Von der Business-Strategie zum technischen Design
- subtitle
- Vladislav Khononov
- introduction
- Seiten: 342 · Verlag: O‘Reilly, 2022 ISBN Print: 978-3-96009-195-0 Sprache: Deutsch
- image
- cover_Einführung in Domain-Driven Design
