domains / families / software-engineering / domain-driven-design

domain-driven-design

combined

Apply Eric Evans-inspired DDD rules when modeling a complex domain, defining bounded contexts, protecting ubiquitous language, or designing aggregates. Plan and route Domain-Driven Design work from strategic modeling to tactical implementation and evented architecture patterns.

When to use

• You need to model a complex business domain with explicit boundaries.
• You want to decide whether full DDD is worth the added complexity.
• You need to connect strategic design decisions to implementation patterns.
• You are planning CQRS, event sourcing, sagas, or projections from domain needs.

When not to use

• The problem is simple CRUD with low business complexity.
• You only need localized bug fixes.
• There is no access to domain knowledge and no proxy product expert.
• This skill does not replace direct workshops with domain experts.
• It does not provide framework-specific code generation.
• It should not be used as a justification to over-engineer simple systems.

Skill page

Conflict

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).