Strategic DDD / Buy vs. Build¶
Tactic DDD update¶
- Aggregates können auch Events austauschen (Message Queue System)
Aggregate Best Practices¶
- Aggregates kommunizieren asynchron (mit MQ) miteinander
- Aggregates sollen separat deploybar sein
- Keine verteilten Transaktionen
Bounded Context¶
- "Beschränkter" Context (Boundary)
- Meist ein Subsystem oder die Arbeit eines Teams
- Innerhalb der Boundary soll z.B. "ubiquitous" language gelten
- Grenzen sind eindeutig und explizit definiert
Subdomain Pattern¶
- Die ganze Problemdomäne aufteilen in Subdomains
- Funktionale Anforderungen aufteilen
- SE2: Partitioning vom Domain Model
- Die Lösungsdomäne (design-level domain model) in bounded Contexts aufzuteilen
- Unterschied zum Bound Context:
- BC ist im Solution Space, Subdomains im Problem Space
- Subdomains sind im Logical / Scenario Viewpoint angesiedelt, Bounded Contexts im Viepoint Implementation / Process
- In "idealer" Welt Mappen Subdomains und BCs 1:1
- Realität eher n:m, eine Subdomain kann z.B. in mehreren BC vorkommen
Context Map Pattern¶
- Technik, um Bounded Contexts zu verbinden und die Beziehungen dazwischen zu verbinden
- Den Beziehung einen Typ zuweisen
- Die Typen unterscheiden sich in Sachen Einfluss (coupling) und (a)symmetrie
- Published Language: Die BCs einigen sich auf eine gemeinsame Sprache, z.B. ein XML-Schema über einen ESB, über die sie interagieren können
- conformist: Ein BC "folgt" einem Anderen, hat keinen Einfluss auf das Interface des anderen BC
- partnership: Einigung, gemeinsame Aggregates zwischen BCs
- shared kernel: Gemeinsamer Kernel (z.B. library) - enge Kopplung
- Open Host Service: z.B. Offene API mit Doku, kann von jedem anderen BC verwendet werden (Published Language wird "exposed")
- Customer/Supplier: Customer kann Interface auch beeinflussen
- Anti Corruption Layer: Adapter implementieren, um sich vor Änderungen des Interfaces zu schützen
Lesen als z.B. "Authorization Context ist OHS für Produktmanagement Context"
Info
Context-Map Aufgabe (oder ähnliche) kommt oft in Prüfung!
Buy vs. Build¶
PoT - Proof of Technology¶
- Scope kleiner als bei PoC
- Soll nur zeigen, dass eine Technologie oder Library funktioniert, wie sie soll
- Nicht auf das konkrete Projekt bezogen