event-sourcing-cqrs

Write-side state should contain only fields a command handler needs to enforce invariants. Ask whether a handler would fail or emit incorrect events without the field; if not, move it to a read model. Use multiple focused IHoldState interfaces per handler rather than one large state blob.

Commands are imperative-tense requests that can be rejected, like RelocateCustomer. Events are past-tense facts that already happened and cannot be rejected, like CustomerRelocated. Commands carry only the data the operation needs; events capture business intent, not just state changes.

Use the cheapest rung of Greg Young's migration ladder: weak schema with tolerant readers first, then upcasting old events during deserialization, then double publish. Disk rewrites like copy-replace or copy-transform are last resorts. A new event version must be convertible from the old version.

Ordinal encoding writes a meaningless integer whose interpretation depends on the enum's declaration order, so renumbering silently rewrites every stored event's meaning. Persist by name, or use explicit numbered schemas with reserved ranges and CI enforcement like Protobuf and buf breaking.

Avoid CQRS for simple domains or CRUD-heavy bounded contexts, since it adds risky complexity per Martin Fowler. Apply it only to specific bounded contexts with genuine domain complexity or where reads and writes must scale independently, never across an entire system.

Projections subscribe to the event stream, persist a checkpoint after each event, and resume from that position on restart. Handlers must be idempotent because delivery is at-least-once, and any read model can be dropped and rebuilt by replaying from position zero.