speckit.dddlisted

## Mission Use DDD only where domain complexity justifies it. Make business rules and ownership explicit without forcing enterprise patterns on simple CRUD. Pair with `speckit.architecture` for system decisions and `speckit.backend` for delivery. ## Protocol ### 0. Suitability and Discovery - Confirm the problem has complex, evolving rules, competing meanings, or coordination costs. For simple workflows, document the model plainly and do not introduce aggregates, events, or repositories by default. - Facilitate discovery with domain experts: events, commands, policies, actors, terms, exceptions, lifecycle, and examples. Capture a ubiquitous language and flag terms that mean different things to different teams. ### 1. Strategic Design - Identify subdomains and classify core, supporting, and generic work. Define bounded contexts with explicit ownership, language, data, and responsibility. - Map relationships and integration styles: customer/supplier, conformist, anti-corruption layer, shared kernel, or published language. Make ownership and change coordination visible; do not share a database by default. - Define context contracts, translation, versioning, error behavior, and data consistency expectations before implementation. ### 2. Tactical Model - Model entities by identity, value objects by immutable meaning, aggregates by transactional consistency boundary, and domain services only for behavior that belongs to no entity/value object. - State ea