nw-ddd-tacticallisted

# Tactical DDD Implementation patterns within a bounded context. Tactical DDD answers: "How do we structure the domain model?" ## Aggregates An aggregate is a consistency boundary -- a cluster of domain objects that must be transactionally consistent. ### Vernon's Four Design Rules 1. **Model true invariants in consistency boundaries**: Only include elements that MUST be consistent within the same transaction. If two entities don't share an invariant, they belong in separate aggregates. 2. **Design small aggregates**: ~70% of aggregates contain only a root entity with value-typed properties. Large aggregates create concurrency contention, scalability failures, and memory pressure. 3. **Reference other aggregates by identity**: Use `ProductId` not `Product`. Direct object references create accidental cross-aggregate transactions and prevent independent scaling. 4. **Use eventual consistency outside the boundary**: Domain events communicate across aggregates. One transaction = one aggregate. If you need to update two aggregates "atomically," reconsider your boundaries. ### Aggregate Design Checklist - [ ] Contains only elements sharing true invariants - [ ] Root entity controls all access (no direct child manipulation) - [ ] External references by ID only (no object graphs) - [ ] Small enough for single-transaction performance - [ ] Command produces events (in event-sourced systems) or mutates state (in traditional) - [ ] Business rules validated in command handling,