Die Sprachverwirrung
Bei meiner Arbeit als Trainer für Domain-Driven Design (kurz: DDD) merke ich, dass die Teilnehmer (m/w/d) meines DDD-Trainings gelegentlich Probleme haben, fünf Begriffe genau auseinander zu halten:
- Domain
- Subdomain
- Context
- Bounded Context
- Module
Da werden Subdomänen mit Bounded Contexts verwechselt, oder das Wort Modul munter als Synonym für Subdomäne und Bounded Context verwendet. Draußen im Web passieren auch oft solche Verwechslungen.
Ja, diese Dinge haben wirklich viel miteinander zu tun, doch sie sind eben nicht dasselbe! Und es ist wichtig, sie auseinander zu halten, damit alle im Team (Fachleute und Entwickler) wissen, worüber gerade gesprochen wird. Lassen Sie uns das in diesem Artikel “kurz mal eben” tun.
Domänen und Modelle
Eine Domäne (domain) ist ein Bereich von Wissen und Einfluss, deren Probleme durch unsere Software gelöst werden sollen. Handel, Bankwesen, Telekommunikation, das sind extrem große Domänen. Durch Unterteilen in Subdomänen will man sie in Gesprächen verständlich und beherrschbar machen. Beispielsweise könnte man Bankwesen unterteilen in die Subdomänen Sparen, Investieren, Kreditvergabe, Zahlungsverkehr und vieles mehr. “Investieren” kann man wieder unterteilen in Subdomänen wie z.B. den Handel mit Aktien, Edelmetallen oder Immobilien.
Ein Domänenmodell ist eine Abstraktion, ein vereinfachtes Abbild einer Domäne oder Subdomäne. Dieses vereinfachte, auf das wesentliche reduzierte Abbild macht man sich, damit man mit mehreren Personen, z.B. Fachbereich, Benutzer und Entwickler, darüber leichter sprechen kann, ohne jedesmal die ganzen Details zu brauchen. Alle diese Modelle sind also bewusst ungenau und dadurch sehr nützlich.
Domänen und Subdomänen sind “draußen” in der Wirklichkeit, außerhalb des Kopfs eines einzelnen Betrachters. Domänenmodelle sind “drinnen” in den Köpfen, als Abstraktionen, Ideen und Konzepte, oder ebenso “drinnen” in den Maschinen als formale Modelle, speziell auch als ausführbarer Code, der ja ebenfalls ein Modell (also eine vereinfachte Abstraktion des Wirklichen) ist.
Kontexte
Während man Domänen noch relativ gut versteht, beginnt beim Wort Kontext meist die Konfusion. Das liegt daran, dass es mehrere Anwendungen des Wortes “Kontext” gibt. Man kann es linguistisch definieren, oder sozial, oder strikt auf Domänenmodelle bezogen.
Ein linguistischer Kontext z.B. ist eine Umgebung oder Situation, die den Wörtern oder Aussagen, die darin erscheinen, einen Sinn verleiht. Nehmen wir die Wörter “Natur”, “Wald”, “Berg”, und “See”, so werden diese im Kontext der Biologie etwas anderes bedeuten als im Kontext der Touristik, obwohl in gewissem Sinne ein Wald in beiden Kontexten ein Wald ist, weil er ein großes Ökosystem ist, das aus Bäumen besteht.
Ein sozialer Kontext ist die Menge von Leuten, die mit demselben Wort auch dasselbe meinen. In einer Firma kann ich erkennen, dass die Sales-Leute in etwa ähnlich von einem Kunden reden, die Support-Leute untereinander auch ähnlich, doch deutlich anders anders als die Sales-Leute, obwohl beide das Wort “Kunde” benutzen. Kontexte können also auch Gruppen von Menschen sein, hier “Sales” und “Support”.
Auf Domänenmodelle bezogen sprechen wir von einem Bounded Context, das ist die Umgebung oder Situation, in der ein Domänenmodell anwendbar, bedeutungsvoll und gültig ist. Beispiele: ein bestimmtes Team, ein bestimmter Teil der Anwendung, oder eine bestimmten Codebasis. Ein Bounded Context muss sich abgrenzen lassen, die Grenze muss erkennbar und beschreibbar sein, sonst ist es kein Bounded Context. Ein Bounded Context liefert einen Rahmen für ein Stück Domänenmodell, ist also im Sinne des vorherigen Abschnitts ebenfalls “drinnen”, in der Vorstellung, nicht in der Realität.
In meinen DDD-Schulungen unterrichte ich u.a. die Techniken “Event Storming” und “Context Mapping”, also das Zeichnen von Kontextlandkarten. Im Event Storming gefundene, linguistische Kontexte, werden in der Context Map zu Bounded Contexts. Diese ergeben eine exzellente Grundlage für die Grenzen, anhand derer man schlagkräftige, autonome, agile Teams, also soziale Kontexte, bilden kann.
Plötzlich wird klar, wie Sprache, Modellierung und Soziales zusammenhängen können und sollen, damit man erfolgreiche Entwicklungsorganisationen erschaffen kann.
Module
Wenn dann als Drittes noch der im DDD ebenfalls verwendete Begriff “Modul” (module) hinzukommt, ist die Verwirrung meist komplett. Das liegt einerseits wieder daran, dass es verschiedene Sichtweisen auf Module gibt, andererseits auch an der großen Ähnlichkeit von Modulen zu Bounded Contexts. Zunächst zu den Sichtweisen: Es gibt konzeptionelle Module, Module im Modell und Module als Namensräume.
Ein konzeptionelles Modul ist eine Sammlung zusammenhängender Konzepte, über die man unabhängig von anderen Konzepten reden kann. Die Konzepte innerhalb eines Moduls sollten etwas miteinander zu tun haben, nicht eine Suppe gemischter Ideen darstellen. Module sollen so geschnitten sein, dass man über ein Modul reden kann, ohne über die anderen reden zu müssen, mit denen es zusammenhängt. Insgesamt sollte man mit Hilfe der Module die Geschichte des Systems erzählen können. Beispiel: Wenn ein Kunde etwas bestellt, und es ist gerade nicht am “Lager”, muss der “Einkauf” es nachbestellen. Zum Zeitpunkt des “Wareneingangs” benachrichtigen wir den “Versand”, der die Nachlieferung an den Kunden veranlassen kann. Lager, Einkauf, Wareneingang und Versand sind also gute Modulnamen, mit deren Hilfe man den Handelsprozess nacherzählen kann.
Ein Modul im Modell dient zur Partitionierung des Domänenmodells entlang von high-level Domänenkonzepten. Also gäbe es im Domänenmodell eben wahrscheinlich auch ein Modul “Einkauf”, das sich mit den Einkaufsprozessen beschäftigt.
Ein Modul ist immer auch ein Namensraum (package oder name space). Die Namen der Dinge innerhalb des Moduls gelten nur zusammen mit dem Namen des Moduls, also nicht außerhalb. Ein Artikel im Wareneingang kann etwas “leicht” anderes sein als ein Artikel im Einkauf. Schwierig, oder? Doch dafür sind Module ja unter anderem da, nämlich um Strukturen zu bilden, in denen man sich noch auskennt.
Die Konfusion kommt jetzt meist daher, dass man aus konzeptionellen Modulen oder aus Subdomänen später auch Bounded Contexts bilden kann. Oder man könnte einen einzelnen Bounded Context, der vielleicht immer noch zu groß ist, in weitere Module unterteilen. Spätestens jetzt muss man alle diese Dinge sauber auseinanderhalten, damit andere noch wissen, wovon man gerade spricht.
Konfusion bei 1:1 Beziehungen
DDD-Anwender (und die Teilnehmer in meinen Schulungen) finden es anfänglich besonders schwierig, diese Dinge auseinander zu halten, sobald sie nur einmal auftreten und/oder alle gleich heißen.
Beispiel: Eine Domäne X mit nur einem Bounded Context X und einem Top-Level-Modul, das genauso X heißt wie der Bounded Context und die Domäne.
Sobald das zu lösende Problem zu einfach wird, weiß man oft nicht mehr, warum und wann man Domänen, Bounded Contexts oder Module braucht und wann man nun welches nimmt.
In dem Fall: Lieber zuerst etwas “Mittelschwieriges” modellieren, damit die Motivation und die Unterschiede klar werden, und später etwas sehr Einfaches, um die entstehenden 1:1-Spezialfälle als solche zu identifizieren. Am Schluss etwas sehr Schwieriges modellieren und dabei mit dem Gelernten “voll zuschlagen”.
Zusammenfassung
OK, also, was haben wir jetzt?
TL;DR:
- Eine Domäne ist ein Bereich von Wissen und Einfluss, deren Probleme durch unsere Software gelöst werden sollen.
- Ein Kontext ist ein Rahmen, der den Dingen, die darin sind, linguistisch, modellierungstechnisch, oder sozial eine Bedeutung verleiht.
- Ein Modul ist eine “Tüte”, in die man etwas hineinpackt und auf die man einen neuen Namen schreibt, um insgesamt darüber als “eins” reden zu können
Man kann Module benutzen, um Subdomänen und Kontexte näher zu beschreiben oder um einfach nur etwas feiner zu strukturieren.
Mehr Info
Wenn Sie diese Dinge genau wissen und selbst können möchten, kommen Sie in meine DDD-Trainings. Dort erkläre ich auch, wie man eine Begriffswelt auf die andere abbildet, z.B. aus wie vielen DDD-Bausteinen ein Event Storming-Aggregate besteht, oder aus wie vielen Code-Elementen ein DDD-Aggregate bestehen kann.
- Wenn Sie Domain-Driven Design methodisch beherrschen lernen wollen, kommen Sie in mein DDD-Training.
- Wenn Sie es auch technisch, also im Code, beherrschen wollen, kommen Sie in mein DDD-Camp.
Literatur
- Evans, Eric (2004), Domain-Driven Design: Tackling Complexity In the Heart of Software. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.
- domainlanguage.com (2016), DDD Reference
Titelfoto
vielen Dank an den Fotografen Hans-Peter Gauster:
Unsplash
