Domain-Driven Design (DDD): Strategic Hub & Workshop

"The heart of software is its ability to solve domain-related problems for its user." — Martin Fowler.

Strategic DDD is about taming complexity by identifying what to build and how to organize teams around Bounded Contexts.

🌪 Virtual Event Storming Workflow

Use this workflow to discover domains through a collaborative workshop with AI:

• Big Picture: Identify all Domain Events (Past tense: e.g., OrderPlaced ).

• Commands: Identify the triggers for those events (e.g., PlaceOrder ).

• Policy & Logic: Define rules that link commands and events.

• Aggregate Identification: Group related commands/events into consistency boundaries.

• Bounded Context Mapping: Group Aggregates into logical contexts.

🎯 Subdomain Types (ROI Focus)

• Core Domain: Your unique competitive advantage. High complexity, high value. Strategy: Build in-house with top talent.

• Supporting Subdomain: Necessary but not a differentiator. Medium complexity. Strategy: Build or use open-source.

• Generic Subdomain: Standard problems with off-the-shelf solutions. Strategy: Buy/Use SaaS.

🔗 Context Mapping Patterns (Upstream/Downstream)

• ACL (Anti-Corruption Layer): Translates external models to your internal domain. (Highly recommended to shield Core Domains).

• OHS (Open Host Service): A public API for your domain.

• Shared Kernel: Two contexts sharing part of the model (High risk, use sparingly).

• Conformist: Downstream team strictly follows the upstream model.

🚫 Strategic Anti-Patterns

• The Generic Core: Wasting top talent on building generic things (like Auth).

• Context Leakage: Using a model from one Bounded Context directly in another without translation (ACL).

• Anemic Bounded Context: A context that has no clear responsibility or ubiquitous language.