My Journey in Learning Domain-Driven-Design part3 (CQRS)

ch4-p140 implementing domain-driven design [Vaughn Vernon]

Why using CQRS?

some times It can be difficult to query from Repositories all the data users need to view. This is especially so when user experience design creates views of data that cuts across a number of Aggregate types and instances. The more sophisticated your domain, the more this situation tends to occur. we can use multiple repositories to fetch data and assemble them into DTO(Data Transfer Object)

Commands and Queries definitions:

Commands: it is a method that modifies the state of the object, and its method must not return a value.

Asynchronous CQRS approach using Messaging System and Event Store

Query Models:

The query model is a denormalized data model. It is not meant to deliver
domain behavior, only data for display (and possibly reporting). If this data
model is a SQL database, each table would hold the data for a single kind
of client view (display). The table can have many columns, even a superset of
those needed by any given user interface display view. Table views can be created from tables, each of which is used as a logical subset of the whole.

Command Models:

A Command is behavior-centric and not data-centric. It is about the intent to change something, it does not map to the format of a resource (like DTOs in an API). It can contain data that will help to process the intent but that’s it.

Updating Query Models:

A special subscriber registers to receive all Domain Events published by the
command model. The subscriber uses each Domain Event to update the query
model to reflect the most recent changes to the command model. This implies
that each Event must be rich enough to supply all the data necessary to produce the correct state in the query model.

Should the updates be performed synchronously or asynchronously?

It depends on the normal load on the system, and possibly also on where the
query model database is stored. Data consistency constraints and performance requirements will influence the decision.

Conclusion:

Like any pattern, CQRS is useful in some places, but not in others. should only be used on specific portions of a system and not the system as a whole. In this way of thinking, each Bounded Context needs its own decisions on how it should be modeled. So avoid adding unnecessary complexity if not needed.

References:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store