cqrs-aggregate-modeling

CQRS lets an aggregate keep only the minimal state needed to validate commands, since read responsibilities move to a separate read model. Fields used only for display or querying are removed from the aggregate, making it smaller and faster to load and update.

Classify each field by asking whether command validation requires it. Data needed for invariants, such as member IDs for permission checks, stays in the aggregate, while display-only data like message text moves to the read model.

Aggregates become slow when they hold large collections of query-only data, forcing full reads and full-row updates for small changes. Splitting query data into a read model and appending events instead of rewriting state resolves this.

Events should contain the full data needed to build the read model, such as message text and sender, even if the aggregate itself only tracks IDs. The aggregate restores minimal state from events while the read model consumes the complete payload.

Reconsider strong consistency when introducing CQRS, since not all related data needs immediate consistency. Keep strong consistency only where behavior requires it, such as membership validation, and let eventually consistent read models handle the rest.