© Matej Kotula/Shutterstock.com
DDD und Microservices

Was lange währt ...


Weder Domain-driven Design (DDD) noch Microservices sind konzeptionell neu. Trotzdem erfahren beide Themen seit einigen Jahren zunehmend mehr Zuspruch und werden immer häufiger auch gemeinsam genannt. Woran liegt das?

Domain-driven Design (DDD) ist eine Entwicklungsmethode, deren Ziel eine gemeinsame fachliche Sprache innerhalb eines interdisziplinären Teams ist. Gelingt das, können sich alle Beteiligten – Fachexperten, Designer und Entwickler – über die gleiche Thematik unterhalten, ohne dass es zu Missverständnissen und impliziten Annahmen kommt. Die Idee ist, dass ein Team durch das Überbrücken der (fach-)sprachlichen Hürden schneller und besser in der Lage ist, die gewünschte Software zu entwickeln. Diese Annahme ist durchaus berechtigt, da es keine Seltenheit ist, dass man zwar miteinander redet, aber dennoch aneinander vorbei. Verwenden alle die gleichen Begriffe und haben auch das gleiche Verständnis dieser Begriffe, verbringt man weniger Zeit mit der Frage nach dem eigentlichen Sinn.

Doch das ist zugleich der Grund, warum DDD vielen Entwicklern so schwerfällt: Es hat wenig bis gar nichts mit Technologie zu tun, sondern mann muss seine persönliche Komfortzone verlassen und sich mit einer fremden Fachthematik auseinandersetzen.

Software ist kein Selbstzweck

Software wird nicht geschrieben, weil es so viel Spaß macht, sondern um fachliche Probleme zu lösen und das Leben einfacher, sicherer oder komfortabler zu machen. Software ist meist nur Mittel zum Zweck – und genau das rückt DDD in den Vordergrund.

Beginnt man, sich auf DDD einzulassen, wird man zunächst von einer Reihe wenig verständlicher Begriffe erschlagen. Commands oder Domain Events mögen noch greifbar erscheinen, aber Aggregates oder Bounded Contexts sind schon deutlich abstrakter. Leider ist auch die gängige Literatur zu DDD keine allzu große Hilfe, da sie sehr abstrakt und akademisch geschrieben ist. Es ist eine Ironie des Schicksals, dass eine Methode, die ein besseres Verständnis anstrebt, oft daran scheitert, wie sie erklärt wird. Ohne auf die Details von DDD eingehen zu wollen, kann man für alle genannten Begriffe einfache, greifbare Definitionen finden:

  • Ein Command ist der Wunsch eines Anwenders, ein bestimmtes Ziel zu erreichen. Commands drücken eine Intention aus und werden oft im Imperativ formuliert. Daher stehen die Formulierungen von Schaltflächen und Menüpunkten in taskorientierten Benutzeroberflächen häufig in dieser Form: Open Game, Move Figure oder Give up sind typische ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang