© Matej Kotula/Shutterstock.com
Teil 5: DDD und Microservices

Was lange währt, wird endlich gut


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 – vom Fachexperten über den Designer bis hin zum Entwickler – über die gleiche Thematik unterhalten, ohne dass es ständig zu Missverständnissen und impliziten Annahmen kommt.

Die Idee dahinter ist, dass ein Team durch das Überbrücken der ansonsten gegebenen (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 jedoch alle die gleichen Begriffe und haben zudem alle auch das gleiche Verständnis dieser Begriffe, verbringt man weniger Zeit mit der Frage nach dem eigentlichen Sinn.

Das ist allerdings zugleich auch der Grund, warum DDD so vielen Entwicklern so schwerfällt: Es hat wenig bis gar nichts mit Technologie zu tun, sondern erfordert, dass man seine persönliche Komfortzone verlässt und sich mit einer bislang fremden Fachthematik auseinandersetzt. Das ist für einen Technologen viel schwieriger, als sich mit den neuen (technischen) Features des jeweils favorisierten Frameworks zu befassen.

Software ist kein Selbstzweck

Software ist aber kein Selbstzweck. Software wird nicht geschrieben, weil es so viel Spaß macht, Software zu schreiben. Letztlich wird Software geschrieben, um fachliche Probleme zu lösen und das Leben von Menschen und/oder Tieren einfacher, sicherer oder komfortabler zu machen. Software ist, auch wenn Entwickler das nicht gerne hören, in den meisten Fällen nur Mittel zum Zweck – und genau das rückt DDD in den Vordergrund.

Fängt man an, sich auf DDD einzulassen, wird man zunächst von einer Reihe wenig verständlicher Begriffe erschlagen. Dinge wie Commands oder Domain Events mögen noch greifbar erscheinen, aber Aggregates oder Bounded Contexts sind da schon deutlich abstrakter. Leider ist auch die gängige Literatur zu DDD dabei keine allzu große Hilfe, da sie sehr abstrakt und akademisch geschrieben ist. Es ist eine gewisse Ironie des Schicksals, dass ausgerechnet eine Methode, die ein besseres Verständnis anstrebt, zu oft daran scheitert, wie sie erklärt wird.

Ohne auf die Details von DDD eingehen zu wollen, kann man jedoch für alle genannten Begriffe einfache, greifbare Definitionen finden:

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

  • Ein Domain Event ist das Resultat auf ein Command: Es ist ein Fakt, der durch das System als Reaktion auf ein Command entstanden ist. Da Fakten tatsächlich geschehen sind und ohne Zeitmaschine nicht mehr rückgängig gemacht werden können, stehen sie in der Vergangenheitsform: Game opened wäre das Pendant zu einem der zuvor genannten Commands. Während Commands also quasi Requests beschreiben, stehen Domain Events für die Responses.

  • Ein Aggregate ist schließlich das Ding, das den Zustand verwaltet, auf dem Commands und Domain Events gemeinsam operieren: Im Falle einer Partie Schach ist ein laufendes Spiel zum Beispiel ein Aggregate, da die genannten Commands Informationen über das laufende Spiel und den aktuellen Spielstand benötigen, um Entscheidungen zu treffen. Der Bezug zu Objekten in der objektorientierten Programmierung liegt nahe, Aggregates müssen aber nicht zwingend als Objekte implementiert werden.

  • Ein Bounded Context schließlich ist eine Sprachgrenze: Er löst das Problem, dass Sprache zwar eindeutig sein soll, aber keine universelle Sprache gewünscht ist. Stattdessen definiert man Bereiche, innerhalb derer die Sprache eindeutig sein muss. Der gleiche Begriff darf aber durchaus in verschiedenen Bounded Contexts in unterschiedlicher Bedeutung auftreten, nur eben nicht innerhalb eines solchen.

Von DDD zu Microservices

Microservices haben hingegen so gar nichts mit DDD zu tun – sie stehen nicht einmal im Zusammenhang mit Fachlichkeit. Stattdessen sind sie höchst technische Artefakte: Ein Microservice ist ein Prozess (im Betriebssystemsinn), der für eine in sich geschlossene Thematik zuständig ist, diese kapselt, und den Zugriff darauf nur über wohldefinierte Schni...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang