Write Model
The domain-owned, transactional model where commands are handled and invariants are enforced.
A write model is the source of truth that commands change and invariants protect.
When a command comes in, the write model loads the current state, checks the rules, and persists the result. In DDD terms, this is where your aggregates live, loaded and stored through repositories.
A typical non-event-driven application has only write models: database tables and rows, updated in a transaction. CQRS introduces read models, letting you separate write models from views. Eventual Consistency is the lag between the two.
architecture patterns
References
- How to use basic CQRS in Go: Shows how queries can start by reading from the write models database before introducing separate read model storage. Discusses when a separate database built from events is worth it.
- Common Anti-Patterns in Go Web Applications: Explains why the data you store in the database (write models) is not the same thing as the views your API returns (read models), and lists CQRS with separate read and write models as a way out of coupled models.
