Skill

domain-modeling

Guides Domain-Driven Design for complex business logic: aggregates, bounded contexts, ubiquitous language, value objects, entities, and TypeScript implementations with invariants.

TypeScript

backend

npx claudepluginhub rnavarych/alpha-engineer --plugin billy-milligan

Popularity

Parent stars

Parent forks

Invocation

How this skill is triggered — by the user, by Claude, or both

Slash command

/billy-milligan:domain-modeling

User invocable

Model invocable

Inline context

Default effort

Tool Access

This skill is limited to the following tools:

ReadGrepGlob

Context Preview

The summary Claude sees in its skill listing — used to decide when to auto-load this skill

- Designing domain model for complex business logic

Supporting Files

assets/domain-model-template.mdreferences/aggregate-design.mdreferences/ddd-decision-guide.mdreferences/ddd-strategic.mdreferences/domain-glossary.mdreferences/event-driven-integration.mdreferences/event-storming.mdreferences/term-conflict-resolution.mdreferences/ubiquitous-language.md

SKILL.md

39 lines · ~583 tokens

Similar Skills

domain-driven-design

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.

system-design

ddd

Guides Domain-Driven Design workflows: domain discovery, ubiquitous language, event storming, bounded contexts, aggregates, entities, value objects, domain events, repositories. For complex business logic beyond CRUD.

godmode

domain-driven-design

1.3k

Models software around business domains using bounded contexts, aggregates, and ubiquitous language. Guides splitting monoliths into services and aligning code with business processes.

6 files

code-craftsmanship

Stats

LanguageShell

Parent stars13

Parent forks1

MaintenanceExcellent

Last CommitMar 5, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Stats

Actions

Help us improve

Share bugs, ideas, or general feedback.

Domain Modeling (DDD)

When to use

Designing domain model for complex business logic

Identifying bounded contexts and aggregate roots

Translating business rules into code invariants

Deciding between entities and value objects

Mapping existing code to DDD building blocks

Core principles

Ubiquitous language is the contract — code names must match business terms; if business says "Invoice", your class is Invoice, not Bill or Document

Aggregates enforce invariants — all business rules for a cluster of objects enforced by the root

Value objects are immutable — Money, Email, Address: no identity, defined by value

Domain events record facts — OrderCancelled not cancelOrder(), past tense

DDD is overkill for CRUD — if it's just data in / data out, use simple CRUD; DDD pays off when business rules are complex

References available

references/ddd-strategic.md — bounded context mapping, context map patterns, ACL implementation

references/ddd-decision-guide.md — DDD vs CRUD decision tree, subdomain classification, team topology alignment

references/event-driven-integration.md — events over sync calls, transactional outbox pattern, event versioning

references/event-storming.md — workshop facilitation guide, sticky note vocabulary, phases 1-7

references/aggregate-design.md — command/event/rule structure, read model derivation, event storming discoveries

references/ubiquitous-language.md — naming convention rules, element type table, what to avoid

references/domain-glossary.md — glossary entry format, e-commerce examples, maintenance cadence

references/term-conflict-resolution.md — 5-step conflict resolution protocol, cross-context disambiguation

Assets available

assets/domain-model-template.md — aggregate skeleton, value object template, repository interface template

Domain Modeling (DDD)

When to use

Designing domain model for complex business logic
Identifying bounded contexts and aggregate roots
Translating business rules into code invariants
Deciding between entities and value objects
Mapping existing code to DDD building blocks

Core principles

Ubiquitous language is the contract — code names must match business terms; if business says "Invoice", your class is Invoice, not Bill or Document
Aggregates enforce invariants — all business rules for a cluster of objects enforced by the root
Value objects are immutable — Money, Email, Address: no identity, defined by value
Domain events record facts — OrderCancelled not cancelOrder(), past tense
DDD is overkill for CRUD — if it's just data in / data out, use simple CRUD; DDD pays off when business rules are complex

References available

references/ddd-strategic.md — bounded context mapping, context map patterns, ACL implementation
references/ddd-decision-guide.md — DDD vs CRUD decision tree, subdomain classification, team topology alignment
references/event-driven-integration.md — events over sync calls, transactional outbox pattern, event versioning
references/event-storming.md — workshop facilitation guide, sticky note vocabulary, phases 1-7
references/aggregate-design.md — command/event/rule structure, read model derivation, event storming discoveries
references/ubiquitous-language.md — naming convention rules, element type table, what to avoid
references/domain-glossary.md — glossary entry format, e-commerce examples, maintenance cadence
references/term-conflict-resolution.md — 5-step conflict resolution protocol, cross-context disambiguation

Assets available

assets/domain-model-template.md — aggregate skeleton, value object template, repository interface template

domain-modeling

Popularity

Invocation

Tool Access

Context Preview

Supporting Files

SKILL.md

Similar Skills

Help us improve

Help us improve

Find plugins for your project

domain-modeling

Popularity

Invocation

Tool Access

Context Preview

Supporting Files

SKILL.md

Domain Modeling (DDD)

When to use

Core principles

References available

Assets available

Similar Skills

Help us improve

Domain Modeling (DDD)

When to use

Core principles

References available

Assets available