void-domain-driven-design

Use small aggregates with a private constructor and a static create method returning Result, so invariants hold by construction. Reference other aggregates by ID rather than embedding full objects, and route every mutation through methods that preserve invariants.

A branded type intersects a primitive with a unique brand tag, like string & { __brand: 'Email' }, so the compiler rejects raw strings. A smart constructor validates input and returns Result<Email, ValidationError> instead of throwing.

Use a class for aggregates with many invariants and behavior methods, such as Order or Account. Use a discriminated union for workflows with distinct data per state, like a BookingFlow, so the compiler enforces valid transitions.

No. CQRS, event sourcing, mediator patterns, and generic Repository<T> are banned by default under the project's philosophy. Reintroducing any of them requires an explicit architecture decision record through the void-decide skill.

Direct imports of another bounded context's types collapse context boundaries into a shared model, which is a big ball of mud. Communication across contexts must go through an anti-corruption adapter that translates between models.

Use a domain service only when an operation spans multiple aggregates, such as transferring funds between two accounts. Single-aggregate operations belong as methods on the aggregate itself to avoid anemic service dumping grounds.