domain-driven-designlisted

# Domain-Driven Design Patterns Pragmatic DDD for TypeScript monorepos. Invest in rich models where complexity justifies it; keep it simple everywhere else. **Research:** `docs/deepresearch/reports/DDD Strategic and Tactical Patterns for TypeScript Monorepos.md` ## Non-Negotiable Rules | # | Rule | Violation Example | Correct Pattern | |---|------|-------------------|-----------------| | 1 | **Bounded contexts expose only IDs/DTOs** | `import { Task } from '@pkg/tasks/internal'` | `import { TaskId } from '@pkg/tasks'` via public index | | 2 | **Same word, different meaning = new context** | Single `Task` class used by workflow engine AND user todo list | Separate `WorkflowTask` and `UserTask` in their own packages | | 3 | **Aggregate = consistency boundary** | 2000-line `Workflow` with tasks, comments, attachments | Small aggregate: only objects sharing same-transaction invariants | | 4 | **Domain events raised inside aggregate** | `service.completeTask(); eventDispatcher.dispatch(...)` outside | `task.complete()` calls `this.addDomainEvent(new TaskCompleted(...))` | | 5 | **Events dispatched after TX commit** | Publish event mid-transaction (rollback = phantom event) | Collect events in aggregate, dispatch after successful DB commit | | 6 | **Classify subdomains before investing** | Full DDD for auth/notifications/file-upload | Core = rich model; Supporting = simple; Generic = buy/outsource | | 7 | **Ubiquitous language in code** | Business says "completed", code says `s