projection

Define a flat Zod schema, infer a Props type, export an event union, and write a plain class with overloaded static create(event) and applyEvent(event) methods that switch on event.name. Pair it with a repository exposing findByKey, save, and insertIfNew.

Add a projection only when the read shape is an expensive denormalization or aggregation, a cross-service consumer needs mirrored fields, or derived columns like counters and ranks are updated by events from many aggregates. Otherwise write a query use case against existing aggregate tables.

Cross-context projections that span multiple bounded contexts live in the ui BFF context under ui/projections/. Domain contexts must not subscribe to events from other domain contexts; that coupling belongs only in the BFF.

Atomic ops are edge cases justified by five named triggers: hot-row contention, bulk updates across N rows, monotonic constraints, conditional updates needing SQL atomicity, and cache-mirror bulk upserts. Each atomic method must carry a comment naming its trigger.

The switch on event.name with a default never case is the mandatory canonical dispatch shape, enforced by detector PS-04. It provides exhaustiveness checking and makes adding a second event a new case rather than a restructure.

No. Projections are free records with no base class, no invariants, no validation, and no domain events. Extending BaseEntity drags write-side baggage like identity and event-raising into a read model, which is flagged as a critical bad practice.