Domain-Driven Design

Model complex domains through deep collaboration with domain experts, making the model the center of the design — not the database, not the framework, not the API surface.

"The heart of software is its ability to solve domain-related problems for its users." — Eric Evans

Skill workflow — DDD pairs naturally with language and architecture: domain-language (formalize the ubiquitous language first) → domain-driven-design (model the domain) → adr (record bounded context decisions)

Philosophy

Software complexity has two kinds of roots: essential complexity (the domain is genuinely hard) and accidental complexity (we made poor decisions). DDD addresses essential complexity by making the domain model the primary artifact of design.

The key insight: the model should reflect how domain experts think and speak. If your code uses different words than your domain experts, there's a translation tax on every feature. That tax compounds.