2.6 KiB
2.6 KiB
name, description, license, metadata
| name | description | license | metadata | ||||
|---|---|---|---|---|---|---|---|
| domain-driven-design | Model business rules and consistency boundaries using domain-driven design. Use when choosing aggregates or bounded contexts, mapping domain relationships, or correcting a mismatch between business language and code. | MIT |
|
Domain-Driven Design
Model the requested business behavior, not an idealized architecture. Start with the user's scenarios, existing code, root CONTEXT.md, and relevant accepted ADRs.
Shared constraints
- Preserve the repository's language and existing architectural decisions. Surface conflicts with evidence rather than silently replacing them.
- Follow the development data lifecycle: replace obsolete development schemas/contracts and update callers and tests together. Compatibility patterns apply only to genuine external constraints or a later explicit production-data decision.
- Choose aggregate boundaries from invariants and ownership. Preserve the accepted rental transaction design, including atomic operations across aggregate documents.
- Add events, factories, translation layers, or separate contexts only for a current business or integration need. Simple CRUD is valid; a score or wider architecture audit is optional, not a completion gate.
- Honor the requested deliverable: a design or review does not itself authorize implementation, migrations, or external changes.
Use the relevant reference
Read only the branch needed by the task:
- Resolving ambiguous terms or maintaining a glossary: ubiquitous language.
- Choosing context boundaries or mapping integrations: bounded contexts.
- Deciding identity, value semantics, aggregate ownership, or atomicity: building blocks.
- Designing a real event flow or evaluating event sourcing: domain events.
- Defining persistence contracts, reconstruction, or complex creation: repositories and factories.
- Prioritizing modeling effort or comparing build/buy choices: strategic design.
Outcome
Explain the proposed concepts, invariant owners, important transitions, and how the design handles failure and concurrency. Show only the alternatives that matter, identify unresolved domain questions, and propose checks that would falsify the design. When implementation is requested, update affected callers, tests, and domain documentation together.