© 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 Beispiele, in diesem Fall aus der Fachlichkeit des Schachs.

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

  • Ein Aggregate ist das Ding, das den Zustand verwaltet, auf dem Commands und Domain Events gemeinsam operieren: Bei einer Partie Schach ist ein laufendes Spiel 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 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 nichts mit DDD zu tun – sie stehen nicht einmal im Zusammenhang mit Fachlichkeit, sondern sind höchst technische Artefakte: Ein Microservice ist ein Prozess (im Betriebssystemsinn), der für eine in sich geschlossene Thematik zuständig ist, sie kapselt und den Zugriff darauf nur über wohldefinierte Schnittstellen von außen zulässt. Microservices sind technisch und inhaltlich autonom und autark.

Diese Beschreibung erinnert stark an die Beschreibung von Web Services, wie sie in den 1990er Jahren im Rahmen von SOAP und SOA (Service-oriented Architecture) geläufig war. Tatsächlich stellen Microservices letztlich genau die gleichen Ideen dar wie vor 25 Jahren – nur unter einem anderen Namen: auf Basi...

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