domains / software-engineering / ddd-modeling / domain-driven-design

domain-driven-design

Skill card

combined

The three copies overlap on DDD concepts but each contains material steps the others lack. wondelai provides a detailed tactical framework (ubiquitous language, bounded contexts, aggregates) and a scoring rubric. ciembor is a thin router to external mini/full rule files. sickn33 provides a strategic routing map, a viability check for when to use DDD, and specific output requirements. Crowning one would hide the strategic routing (sickn33) or the detailed tactical scoring (wondelai).

Repositories

Other copies

Combined skill

# Domain-Driven Design

## When to Use
Use this skill when modeling a complex business domain, defining bounded contexts, or aligning code with business processes. Do not use for simple CRUD or localized bug fixes.

## 1. Viability Check
Before committing to full DDD, verify at least two of the following are true:
- Business rules are complex or fast-changing.
- Multiple teams are causing model collisions.
- Integration contracts are unstable.
- Auditability and explicit invariants are critical.

## 2. Strategic Design
Produce strategic artifacts first:
- Identify subdomains and Core Domain.
- Define Bounded Contexts and Context Mapping strategies (e.g., Anti-Corruption Layer).
- Establish a Ubiquitous Language glossary.

## 3. Tactical Modeling
Apply tactical patterns within bounded contexts:
- **Entities vs Value Objects:** Distinguish identity-bearing objects from immutable attribute-based objects.
- **Aggregates:** Define consistency boundaries with a single root that enforces invariants.
- **Repositories:** Encapsulate collection-like access to aggregates.

## 4. Scoring & Evaluation
Score the domain model (1-10) based on:
- Consistency of Ubiquitous Language in code and conversation.
- Explicit context boundaries with Anti-Corruption Layers.
- Invariants living inside aggregates rather than services.
- Rich behavior in entities (avoiding anemic models).

## 5. Output Requirements
Always return:
- Scope and assumptions.
- Current stage (strategic, tactical, or evented).
- Explicit artifacts produced (glossary, context map, aggregate diagrams).
- Open risks and next step recommendation.

## Routing
- For CQRS/Event Sourcing: Route to specialized evented architecture skills.
- For Context Mapping details: Reference specific mapping patterns (Conformist, ACL, Shared Kernel).