domain-driven-design

Implements Domain-Driven Design patterns including aggregates, value objects, domain events, and bounded contexts.

Updated May 30, 2026
One-click install
npx skills add https://github.com/chloebrett/snitchos --skill domain-driven-design-chloebrett
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-driven-design
Source: https://github.com/chloebrett/snitchos/tree/main/.claude/skills/domain-driven-design
Command: npx skills add https://github.com/chloebrett/snitchos --skill domain-driven-design-chloebrett

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Complex business domains often produce codebases where business rules are scattered across route handlers, database queries, and formatting code, making the system hard to reason about and evolve. This Skill provides structured guidance for modeling domains with ubiquitous language, value objects, entities, aggregates, domain services, and bounded contexts so business logic stays isolated and testable. ## Core Features & Use Cases - Domain Modeling Building Blocks: Guidance for value objects, branded types, entities, aggregates, specifications, and discriminated-union state modeling that makes illegal states unrepresentable. - Layered Decision Framework: A placement framework for deciding whether code belongs in domain, use case, adapter, or presentation layers, plus error modeling with result types versus exceptions. - Deep-Dive Resources: On-demand references covering aggregate design, domain events (Decider pattern, outbox, process managers), bounded contexts with anti-corruption layers, and layer-by-layer testing strategy. - Use Case: When building a gift-pledging feature spanning multiple aggregates, use this Skill to model the domain service, enforce invariants at aggregate roots, and test the use case with in-memory fakes. ## Quick Start Ask the AI to apply domain-driven design to model a new feature with value objects, an aggregate root, and a use case tested with in-memory repository fakes.

Frequently Asked Questions about domain-driven-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide where business logic belongs in DDD?

Ask whether the code enforces a business rule or computes a business value. If yes, it belongs in the domain layer as an entity function, value object, or domain service. Orchestration without logic goes in use cases, formatting goes in presentation, and external system calls go in adapters.

What is the difference between a domain service and a use case?

A domain service contains business logic operating across multiple aggregates and takes only domain types as parameters. A use case performs orchestration only, loading aggregates through repository ports, calling domain services, and saving results, identifiable by taking ports as parameters.

When should I use domain events versus explicit return values?

Use explicit return values when side effects stay within one aggregate or transaction. Domain events earn their complexity when side effects cross aggregate boundaries, other bounded contexts must react, or you need an audit trail. Start without events and add them when coordination demands it.

How do I size aggregates correctly in DDD?

Include only what is needed to enforce a consistency rule, and reference other aggregates by ID rather than embedding them. Ask whether modifying one entity requires checking another's state to maintain an invariant. Start combined and split when you feel performance or concurrency pain.

When should I not use Domain-Driven Design?

Avoid DDD for simple CRUD applications with no business rules, technical or infrastructure-focused projects, and projects without a domain expert to consult. Start with just a glossary and value objects, adding aggregates, events, and bounded contexts only when the domain demands them.

How should DDD code be tested?

Test primarily at the use case boundary with driven ports replaced by in-memory fakes rather than mocks. Complement with direct unit tests for complex pure domain functions and property-based tests for invariants, plus narrow integration tests for adapters and E2E tests for full-stack verification.