ddd-best-practices

Topics in the source

• DDD Best Practices
• Working Style
• Design Workflow
• Heuristics
• Bounded Context
• Aggregate
• Entity vs Value Object
• Domain Service

Use this skill when the main question is how to model a domain, where to draw boundaries, or how to structure collaboration between subdomains. 1. Start from the domain problem, not from technical constructs. 2. Build a Ubiquitous Language before writing any code. 3. Keep Aggregates small — consistency boundary, not convenience grouping. 4. Prefer Value Objects when a domain concept has value semantics, not as a blanket wrapper for every primitive. 5. Let Domain Events tell the story of what happened, not what to do next. 6. Never let infrastructure concerns leak into the domain model. 1. Discover the domain. Who are the domain experts? What language do they use? What are the core subdomains (Core, Supporting, Generic)? Where does the most complex business logic live? 2. Draw Bounded Contexts. One model per context — resist the urge to share models across contexts. Name each context after a team or capability, not a technical layer. Define context relationships explicitly (Partnership, Customer-Supplier, Anti-Corruption Layer, etc.). 3. Design Aggregates. Start from one business command and state the invariants it must preserve. Include only state that must commit or reject atomica

This is an excerpt. Refer to the complete source and its current requirements.