mcpField
D
ddd-design

ddd-design

github.com/yonatankarpDevelopment144 installsUpdated 23w ago
Repository

About ddd-design

ddd-design is a skill for shaping an initial domain model from a feature brief, aimed at teams exploring a new feature or business area. It proceeds through ubiquitous language, bounded contexts, aggregates, and domain events, stopping at a sketch rather than producing code.

Key features

  1. 01Elicit ubiquitous language
  2. 02Define bounded contexts
  3. 03Identify aggregates and roots
  4. 04Propose candidate domain events
  5. 05Stop at a model sketch

Use cases

  1. 01Model a feature with no existing domain model
  2. 02Shape a domain layer for a new project
  3. 03Extend an existing system into a new business area
  4. 04Discuss domain boundaries before implementation

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/yonatankarp/software-design-skills --skill ddd-design

After installing, type/ddd-designin Claude Code to confirm it loaded.

Details

From the project README

One-line summary

Guide a user from a feature brief to a draft domain model: ubiquitous language → bounded context → aggregates → key events.

When to use this skill

  • A new feature with no model yet.
  • Greenfield project starting a domain layer.
  • An existing system being extended into a new business area where no model exists.
  • The user explicitly asks to "design", "model", or "architect" a domain.

When NOT to use this skill

  • Generating code for an already-decided pattern → route to ddd-implement.
  • Transforming existing code → route to ddd-refactor.
  • Auditing code for DDD violations → route to ddd-review.

Core content

Design is a four-step walk. Most of the value lives in the first two steps; the latter two follow once the language and boundaries are clear.

Step 1 — Elicit the ubiquitous language. Ask the user (or a domain expert) to describe the feature in their own words. Capture nouns and verbs verbatim. Push back on jargon that sounds technical ("entity", "record", "DTO") and on overloaded English words. See ddd-ubiquitous-language for the discipline.

Step 2 — Sketch the bounded context. Where does this model end? What model are we not responsible for? Name the upstream and downstream contexts. See ddd-bounded-context and, for the relationships, ddd-context-mapping.

Step 3 — Identify aggregates. From the captured nouns, group those that change together transactionally. Each cluster has one root; external code references only the root. See ddd-aggregate.

Step 4 — Name candidate domain events. Past-tense things the business cares happened (OrderPlaced, RefundIssued). These reveal the seams between aggregates and contexts. See ddd-domain-event.

Decision heuristics

  • Spend roughly 80% of the conversation on language and boundaries (steps 1–2). If the model feels wrong later, it is almost always because step 1 was rushed.
  • If the user resists naming things precisely, that is the work — push back politely.
  • Stop at the sketch. Do not produce code in this skill; hand off to ddd-implement when the user asks for it.

Anti-patterns

  • Jumping straight to entities and attributes before the language is settled.
  • "Let's just put it in one big context" — saves a conversation now, costs a context split later.
  • Designing the database schema in parallel — schema thinking corrupts the model.
  • Producing a class diagram before any verb has been spoken.

See also

  • ddd-ubiquitous-language — the first deliverable of every design session.
  • ddd-bounded-context — where the model ends.
  • ddd-context-mapping — relationships to neighbouring models.
  • ddd-aggregate — clustering entities by transactional consistency.
  • ddd-domain-event — the seams that connect aggregates and contexts.
  • ddd-subdomain-classification — is this even worth modeling deeply?

References

  • Evans, Domain-Driven Design (2003), Part I (Chs 1–3) and Part IV (Chs 14–15).

Comments

Markdown supported