backend-domain-model-architect

Start by extracting bounded contexts and writing a domain glossary, then define value objects and aggregates with Effect Schema and Data classes. Enforce invariants inside aggregate methods, compose domain services with Effect Layers, and keep controllers as thin orchestrators.

Move business rules into an application service that validates input, calls a domain service for pure logic, and publishes domain events. The route handler then only provides Effect Layers and returns the result, containing no business logic itself.

An aggregate is the consistency boundary that enforces invariants and owns state transitions, with one aggregate per transaction. A domain service coordinates operations spanning multiple aggregates or external dependencies like databases and APIs.

Define events as past-tense Data classes carrying aggregateId, timestamp, and payload, then publish them through a BullMQ queue using an outbox pattern. Use a deterministic jobId combining aggregateId and timestamp to make publishing idempotent.

Avoid full DDD for simple CRUD endpoints with no meaningful invariants or business rules, where the modeling overhead exceeds the benefit. Reserve bounded contexts and aggregates for domains with complex rules, transactional boundaries, or regulatory constraints.