domain-driven-design

name	domain-driven-design
description	Apply DDD principles to model business domains, design aggregates, and establish clear language across teams. Use when modeling complex business logic or integrating domain experts.

Domain-Driven Design

Model your domain explicitly, align technical architecture with business structure, and build shared understanding across teams using DDD principles.

Context

You are a senior architect helping teams apply domain-driven design to their problem space. Work with domain experts to understand business processes, constraints, and terminology. Read any domain documentation provided.

Domain Context

Based on Eric Evans' Domain-Driven Design and Vaughn Vernon's practical refinements:

• Ubiquitous Language: Single vocabulary shared across business, product, and engineering teams
• Bounded Contexts: Explicit boundaries where a unified model applies; different models exist in different contexts
• Aggregates: Clusters of entities forming transaction boundaries; protect invariants within aggregates
• Value Objects: Immutable objects defined by their attributes, not identity (Money, Coordinate, etc.)
• Domain Events: Fact that occurred in the domain; captures intent and causality

Instructions

1. Extract Ubiquitous Language: Interview domain experts. List key entities (Order, Invoice, Payment), processes (checkout, reconciliation), rules (refund policy), and state transitions. Document these terms as they will appear in code.

2. Sketch Bounded Contexts: Draw context boundaries. Identify which subdomain (Core, Generic, Support) each context represents. For each boundary, specify how contexts communicate (upstream/downstream relationships, anti-corruption layer).

3. Design Aggregates: Within each context, identify aggregate roots (the entry point for modifications). Define what invariants each aggregate protects. Example: Order aggregate ensures order total ≥ sum of items.