Startseite > .Net, Bücher, Ruby, webRead > Buch-Rezension zu “Domain-Driven Design”

Buch-Rezension zu “Domain-Driven Design”

3. Februar 2013

Domain-Driven DesignWenn man sich mit Behavior Driven Development (BDD) und dem Schreiben von Akzeptanztests beschäftigt stösst man immer wieder auf ein Buch:
Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans.

Dieses Buch gilt weit herum als Standardwerk das man unbedingt kennen muss. Beim Lesen merkt man schnell das Evans sehr viel Erfahrung hat und weiss wovon er schreibt. Leider macht er dies so ausführlich dass man kaum vorwärts kommt. “Man müsse die Informationen herausschürfen” ist eine Bemerkung über dieses Buch die man beim Lesen im Hinterkopf behalten sollte.

 

Kernpunkte

Von all den Themen die Evans behandelt stechen für mich diese Punkte besonders hervor:

Mit Hilfe einer Ubiquitous Language (einer einzigen gemeinsamen Sprache) sollen alle am Projekt beteiligten Personen kommunizieren. Dadurch das alle die gleichen Begriffe benutzen können Missverständnisse und Übersetzungsprobleme (im Sinne von Fachspezifisch zu Technisch) früh erkannt werden oder entfallen ganz. Auch ist es für Entwickler einfacher sich an die Spezifikationen zu halten wenn die Objekte im Code gleich heissen wie in den Anforderungen und den Testszenarios.

Bei Refactoring denkt man meistens an einen technischen Vorgang um Code besser zu strukturieren. Neben diesem technischen Aspekt gibt es aber auch einen fachlichen. Evens zeigt bei „Refactoring Toward Deeper Insight“ auf wie man nach und nach das Domänenmodell um neue Erkenntnisse verfeinern kann.

Entwickelt man nach Model Driven Design darf das Modell nicht in einem Vakuum erstellt werden. Ist dieses Modell technisch nicht umsetzbar wird in der Entwicklung gezwungenermassen eine Lösung gefunden die davon abweicht. Damit verliert man alle Vorteile und muss ständig zwischen mehreren Modellen hin und her wechseln. Neben höheren Kosten leidet dabei auch die Kommunikation.

Bounded Context: Das eigene Domänenmodell kann noch so gut sein, wenn man es nicht abgrenzt fliessen die unterschiedlichen Konzepte der Umsysteme hinein. Evens zeigt eine ganze Reihe von Ansätzen um dies zu verhindern (wie das Pattern “Anticorruption Layer”).

Software-Entwicklung ist mehr als das Schreiben von Code. Es geht um das Lösen von Problemen. Damit man die passende Lösung finden kann ist eine Zusammenarbeit mit allen beteiligten Parteien nötigt.

 

Kritik

Die gleichen Namen und Bezeichnungen zu verwenden ist ein grosser Schritt in die richtige Richtung. Nur ist es damit nicht getan. Mir fehlt wie man auch zu einer gemeinsamen Bedeutung kommt und überhaupt die Wiedersprüche aufdecken kann. (Wenn alle von Autos sprechen, wie merkt man das der eine einen Golf meint und der anderen einen Ferrari?)

Die ersten beiden Teile sind sehr schwerfällig geschrieben. Immer wieder springt Evans von einer Idee zur nächsten und wieder holt dieses hin und her mehrmals. Würde dies aus unterschiedlichen Perspektiven geschehen wäre dies ein Plus fürs Buch. Leider sucht man die ganze Zeit nach den Unterschieden zum bereits behandelten und findet meist keine. Dies bremst den Lesefluss und schlägt auf die Motivation.

Anstelle der vielen Wiederholungen wären Beispiele zur technischen Umsetzung hilfreich. Statt so viel über Code zu sprechen hätte Evens diesen zeigen können – dies ginge schneller und hätte einen Praxisnutzen. So bleibt zu viel eine schöne Idee ohne Hinweis auf deren Umsetzung.

 

Alternative

Abel Avram und Floyd Marinescu sahen ebenfalls einige Verbesserungsmöglichkeiten und schrieben 2006 das Mini-Book “Domain Driven Design Quickly“. Auf rund 100 Seiten gibt es all die Konzepte aus dem Buch von Evans, ein Interview mit ihm und es hat noch Platz für Ergänzungen aus “Applying DDD” von Jimmy Nilsson.

Wer ins Thema DDD einsteigen will sollte sich erst einmal das PDF bei InfoQ herunterladen.

 

Fazit

Mit Domain-Driven Design wurden viele wichtige Ideen erstmals in Buchform veröffentlicht. Die darin behandelten Themen sind auch heute noch aktuell und ein Umsetzen der von Evens vorgestellten Ansätze würde so manches aktuelle Problem lösen.

Leider verzettelt sich Evans mit seinen Erklärungen und macht es dem Leser äusserst schwer diese Konzepte zu verstehen. Als Einstiegslektüre ins Thema DDD kann ich dieses Buch daher nicht empfehlen. “Domain Driven Design Quickly” ist dafür die bessere Wahl, da die gleichen Konzepte viel besser auf den Punkt gebracht werden.
Kehrt man nach diesem Umweg zu Evens zurück versteht man seine Ideen viel besser und erkennt dann auch was sonst noch alles für Informationen in diesem Buch stecken.

 

Zum Buch

Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans, 2003 Addison-Wesley, ISBN 978-0-3211-2521-7, 560 Seiten, Englisch

About these ads
  1. 3. Februar 2013 um 18:28 | #1

    Hi,
    alles was in dieser Rezension steht ist genau richtig.

    Eins steht aber leider nicht drin: IMHO das Buch gehört zu der “Grundausrüstung” jedes Programmierers. Es ist sicherlich keine Einstiegsbuch, aber das hat auch sicherlich keine behauptet…

Die Kommentarfunktion ist geschlossen.
Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 245 Followern an

%d Bloggern gefällt das: