Editing Command–query separation (section)

==Other architectural patterns==
* As we move away from a single representation that we interact with via [[CRUD]], we can easily move to a task-based UI.
* CQRS fits well with event-based programming models. It's common to see a CQRS system split into separate services communicating with Event Collaboration. This allows these services to easily take advantage of [[Event Driven Architecture]].
* Having separate models raises questions about how hard it is to keep those models consistent, which raises the likelihood of using eventual consistency.
* For many domains, much of the logic required is needed when you're updating, so it may make sense to use Eager Read Derivation to simplify your query-side models.
* If the write model generates events for all updates, you can structure read models as Event Posters, allowing them to be Memory Images and thus avoiding a lot of database interactions.
* CQRS is suited to complex domains, the kind that also benefits from [[Domain-driven_design|Domain-Driven Design]].<ref name="FowlerCQRS" />