domain-driven-design

# Domain-Driven Design ## Config Resolution Skill support project-custom. Resolution: 1. Look `.lattice/config.yaml` repo root 2. If found, check `paths.ddd_principles` custom doc path 3. If custom path exist, read doc, check YAML frontmatter `mode`: - **`mode: override`** (or no mode): Custom doc full precedence. Use instead embed default. Must comprehensive -- sole reference. - **`mode: overlay`**: Read embed `./references/defaults.md` first, then apply custom doc section on top. Section custom replace match section default (match by heading). New section append after default. 4. If no config, no path, or path not found, read `./references/defaults.md` 5. **Language adaptation**: If `paths.language_idioms` exist in config, read **"Type System & Object Model"** section and adapt entity, value object, and aggregate implementation patterns to language constructs (e.g., struct vs class, trait vs interface, data class vs record). Language idioms take precedence over pseudocode defaults. Default ship with skill, represent opinionated best practice. Work out box any project. Override only when team have specific standard differ from default. ## Self-Validation Checklist STOP after generate each component. Verify ALL follow before proceed. If check clearly fail, fix code before present. If check judgment call with multiple valid approach (see Ambiguity Signal), flag — present option and reasoning rather than silent choose. 1. **ENTITY VS VALUE OBJECT**: ...