Ich glaube, um zu verstehen, was Stefan mit seiner Kritik meint, muss man darauf schauen, was das Buch genau tut und in welchem Kontext entstanden ist. Ich würde mich für den Gedankengang gern auf taktischen Patterns fokussieren, glaube aber, dass die Argumentationskette generell auch ins Strategic Design zu übertragen ist.
Laut Untertitel des Buches geht es darum Komplexität "anzupacken", also zu helfen, mit ihr umzugehen und sie so beherrschbar zu machen. Kern des Vorgehens ist, wie allgemein bekannt, die ubiquitäre Sprache und das Destillieren der darin vorherrschenden Konzepte in Modellelemente. Damit beschreibt sich der Problemraum. Um den Lösungsraum zu beschreiben hat man jetzt eigentlich erst einmal nur Code. In einer OO-Welt also Typen, Methoden und die Namensgebung dieser.
Die Beschreibung der Building Blocks im Tactical Design war das erste Mal, dass mir das Etablieren einer Mustersprache begegnet ist, die sich aus dem Prozess des Modellierens ergibt und Implementierungsvorgaben etabliert. Vielleicht ist es nur meine Sichtweise auf die Welt, aber Patterns waren bis dahin vor allem technisch geprägt (vor allem das GoF Buch, Gregor Hohpes "Patterns of EAI" vielleicht nicht ganz so stark, aber ähnlich).
In DDD werden zum ersten Mal Konzepte etabliert und zueinander in Beziehung gesetzt, die Regeln definieren, die in die Abbildung der Domäne hineinreichen und somit den Lösungsraum begrenzen und es erlauben ein gemeinsames Verständnis auf höherem Abstraktionslevel zu beschreiben. D.h. wenn ich definiere, X ist ein Aggregat, dann erlaubt mir das Validität bzw. Konformität der Implementierung zu überprüfen, bzw. ein einfacheres mentales Model aufzubauen, weil ich bestimmte Dinge ausschließen kann oder – gegenteilig – weiß, welche Regeln gelten.
Für mich ist das dann eigentlich die Quintessenz des Tactical Design: beim Modellieren ein Auge auf wiederkehrende Muster in der Domäne zu haben, die es mir ermöglichen, bestimmte, generelle Konzepte zu etablieren, die wiederum dabei helfen, bestimmte Sachverhalte des Systems höherwertig zu beschreiben. Damit wird der Satz an Mustern, die im blauen Buch beschrieben werden, ein unvollständiger Katalog, der Weg zu diesem Katalog aber zu dem eigentlichen Werkzeug. Ich finde, das wird recht schnell offensichtlich, wenn man z.B. feststellt, dass für Entities zwar von Identifizierbarkeit geredet wird, es aber einen Identifier als explizites Konstrukt nicht in dem Katalog des Buches gibt. Ich nehme an, dass es im Kontext des Container-Shipment-Beispiels des Buches einfach nicht relevant genug war, um es auf diese nächsthöhere Ebene zu heben. Auch das finde ich eine wichtige Beobachtung. In einem Projekt kürzlich haben wir das Muster "Representations" (als Mapping von Elementen des Domänenmodells auf DTOs) als explizites etabliert und entsprechende Ausgestaltungsregeln definiert, weil es eben Mehrwert brachte, das zu tun.
Dieser Abstraktionsschritt ist im Buch nirgendwo beschrieben, was vermutlich das Phänomen erzeugt, das Stefan umtreibt. Hinzu kommt der Drang, streng definieren und verstehen zu wollen "wie genau das jetzt gemeint und richtig ist". Ich sehe jedoch auch ähnlich wie Eberhard eine gewisse Gefahr, das Kind mit dem Bade auszuschütten. Ich persönlich führe viel lieber mal eine vielleicht überflüssige Diskussion darüber, was genau jetzt ein Aggregat ist, als mühselig Entwicklern die Spielbeschäftigung mit Technik aller Art auszureden.
In diesem Sinne, vielen Dank für die schöne Episode! 👋