Im taktischen Design wird ein Bounded Context explizit und en Detail modelliert. Taktisches Design setzt also auf den Ergebnissen des strategischen Designs auf.
Da taktisches Design aufwendig ist (siehe unten), kommt es nicht für alle Bounded Contexts zur Anwendung. In der Regel werden diejenigen Bounded Contexts modelliert, welche von besonderer geschäftskritischer Bedeutung sind (Core Domäne).
Ziel des taktischen Designs ist es, alle fachlichen Konzepte des Bounded Contexts offenzulegen. Es werden ausschließlich fachliche Aspekte modelliert und keinerlei technologische Aspekte betrachtet. Während das bei Domänen-Objekten kein Problem darstellen sollte, ist es deutlich schwieriger fachliche Konzepte zu modellieren, welche sich hinter Assoziationen zwischen Domänen-Objekten, fachlichen Regeln oder Prozeduren und Verfahren verbergen. (Schlagwort: mache Implizites explizit).
Die Diskussionen über die richtige Modellierung decken so oft tiefer liegende fachliche Konzepte auf. Oft sind es kleine Unstimmigkeiten, welche auf tiefer liegende bis nicht erkannte Konzepte führen.
Dieses Vorgehen stützt sich darauf, dass die Konzepte immer wieder diskutiert und so geklärt werden. Daher ist auch in dieser Phase eine intensive und evolutionäre Zusammenarbeit zwischen Entwicklung und Experten unabdinglich.
Taktisches Design verfeinert das Domänenmodell spezieller Bounded Contexts und liefert ein Designmodell der Fachlichkeit dieses Bounded Context. Dieses Modell basiert auf objektorientiertem Design und beschreibt alle fachlich relevanten Objekte des Bounded Contexts.
Die Bezeichnungen von Objekten, Methoden und Assoziationen nutzen die ubiquitären Sprache, sodass sich die Konzepte im Modell möglichst leicht wiederfinden lassen. In dieser Phase ist es denkbar (häufig sogar die Regel), dass die ubiquitäre Sprache angepasst und erweitert wird.
DDD führt die Pattern des model driven modelling ein. Diese liefern klare Vorgehensweise zur Bewertung und Darstellung von Modellobjekten. So besitzen Entities eine Identität und beschreiben Objekte mit kontinuierlichem Lebenszyklus (also auch mit zugehöriger Persistenz). Value Objects beschreiben im Gegensatz dazu flüchtige Zustände. Aggregate sind eine Aggregation/Hierarchie von Entities und Value Objects. Sie besitzen ebenso wie Entities eine Identität.
[Abbildung 1] gibt einen Überblick über die Pattern. Eine detaillierte Darstellung der Pattern findet sich in [Evans, Kap. 5+6], [Vernon1, Kap. 5-12].
Aber was ist dieses Designmodell eines Bounded Context genau und wie wird es repräsentiert?
Einschub:
Zur Beziehung zwischen Analysemodellen und DDD siehe [Evans, Kap. Model Driven Design).
DDD grenzt sich in der Phase des taktischen Designs explizit von einem Vorgehen ab, bei dem Analysemodelle durch Experten vorgegeben und diese dann durch die Entwicklung umgesetzt werden. Bei einem solchen Vorgehen ist die schnelle Umsetzung von Feedbacks aus der Entwicklung nur schwer möglich und es kommt immer wieder zu Missverständnissen bei der Überführung des Analysemodells in Code.
Tatsächlich wird aber jedes Modell in letzter Konsequenz durch den implementierenden Code repräsentiert. Warum nicht den Code als Modell nutzen (“A Model Expressed in Software” siehe [Evans])? Das Designmodell eines Bounded Context wird daher durch Code repräsentiert. Um als Basis für die Diskussion zwischen Experten und Entwicklung zu dienen, muss es von technologischen Aspekte weitestgehend befreit (so frei wie nur möglich) (siehe [Penchikala] ) und konsequent in der ubiquitären Sprache formuliert sein. Folgendes Zitat beleuchtet dies nochmals:
Later you also add tests that verify the correctness of the new domain object from every possible (and practical) angle. At this point you are interested in the correctness of the expression of a domain concept that is embodied in the new domain object.
Reading the demonstrative client-like test code must reveal the proper expressiveness using the Ubiquitous Language. Domain experts who are non-technical should be able to with the help of a developer read the code well enough to get a clear impression that the model has achieved the goal of the team. This implies that test data must be realistic, and support and enhance the desired expressiveness. Otherwise, domain experts cannot make a complete judgment about the implementation. [Vernon2, Chap 7 ; Timebox Modelling]
Auch im taktischen Design gilt die Fokussierung auf die Fachlichkeit. Daher kann ein solches fachlich zentriertes Domänenmodell durch Code repräsentiert werden und trotzdem Diskussionsbasis sein. Es kann gar nicht genug betont werden, dass dieses Designmodell sich in enger Zusammenarbeit zwischen Entwicklung und Experten entwickelt.Um den Experten die Möglichkeit zu gegeben, das Designmodell besser zu verstehen, bieten sich kollaborative Verfahren wie behaviour driven development (BDD , siehe [Semena]) an. BDD basiert auf Szenarien, welche beispielhaft die Arbeitsweise des Codes beschreiben. Diese Szenarien werden ganz bewusst aus Sicht der Experten formuliert (natürlich in ubiquitärer Sprache).
