domain-driven-design

Domain-Driven Design

Config Resolution

The skill supports project-custom principles. Resolution:

1. Look for .lattice/config.yaml in the repo root.
2. If found, check paths.ddd_principles for a custom doc path.
3. If a custom document exists at that path, read it and check its YAML frontmatter mode:
   • mode: override: the custom doc has full precedence. Use it instead of the embedded default. It must be comprehensive -- sole reference.
   • mode: overlay (or no mode): read the embedded ./references/defaults.md first, then apply the custom doc on top. A custom section replaces the matching default section (matched by heading); new sections append after the defaults.
4. If a custom path is configured but no document exists at it → tell the user which configured path is missing, then read ./references/defaults.md.
5. If there is no config file or no paths.ddd_principles key → read ./references/defaults.md.
6. Language adaptation: if paths.language_idioms is set in the config and the document exists, read its "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.

Self-Validation Checklist

STOP after generating each component. Verify ALL checks before proceeding. If any check fails, fix before presenting. If a check is a judgment call with multiple valid approaches (see Ambiguity Signals), flag it — present options and reasoning rather than silently choosing; if framework:collaborative-judgment is loaded, use its presentation format.

1. ENTITY VS VALUE OBJECT: For each domain object — does the business track individual instances over time? Yes → entity with identity. No → value object, immutable and self-validating.
2. AGGREGATE BOUNDARY: Does a transactional invariant require this object inside the aggregate? If not → reference it from a separate aggregate by ID.
3. RICH BEHAVIOR: Does the entity have methods that enforce business rules, guard state transitions, raise events? If the entity is just a data holder → move logic from services into the entity.
4. VALUE OBJECT COVERAGE: Scan for primitives that should be value objects — string emails, number amounts, raw UUIDs as identifiers → wrap in a validating value object.
5. AGGREGATE COHESION: List the business rules the root enforces. Does every internal entity participate in at least one invariant? If not → it belongs in its own aggregate.
6. DOMAIN EVENTS: Should a domain event be raised — a state transition another aggregate reacts to, a change triggering notification, an audit/compliance requirement? Do not raise events for internal changes nothing reacts to.
7. DOMAIN SERVICE: Does stateless logic spanning multiple entities belong in a domain service rather than an application service? Keep I/O and infrastructure calls out of it.
8. FACTORY: Is complex aggregate creation encapsulated behind a factory method (Order.create(...)) or a standalone factory class? Are initial creation and reconstitution from persistence handled separately?