Bringing an MVC perspective to CQRS.

This article makes the point that the MVC and CQRS patterns are very similar. My hope is that with this "new" understating new development tools bringing the two patterns together can be developed to facilitate our programmers lives.

To compare MVC with CQRS we need undress the later of all technical details regarding its implementation and bring out the focus on how information flows between each of its components and its relationships.

Comparing MVC and CQRS Pattern Structures

If you haven't read the article "Clarified CQRS" from Udi Dahan along with Greg Young posts please do. Both have discovered this pattern and they are the authoritative source of anything regarding CQRS. Having said this, for the sake of this comparison I took the liberty of changing the names of certain things of CQRS:

• The Read Part of CQRS is mapped to Domain View in the diagram above.
• The Command Bus is mapped to the Domain Controller. Here is where Commands are mapped to the calls to domain objects as well as Sagas amongst other things.
• The Domain Model, well is the Domain Model.

One particular leg that probably we are not used to see discussed with CQRS is the one connecting the Domain View with the Domain Model. This leg simply reflects the scenario where the view accesses domain services or the domain model is mapped to the view model using for instance a ORM.

We also have two Event legs. One coming out of the Domain Controller and the another coming from the Domain Model:

• The one coming out from the Domain Controller reflects the scenario where the Command Bus is responsible for publishing domain events as a result of performing an action against a domain object (Udi way I guess);
• The one coming out the Domain Object reflects the scenario when the Repository publishes such events (Greg way I guess).

Choosing one or another depends on what object assures that performing the action and publishing the events occurs in a single transaction.

The MVC is similar to CQRS in the sense that we have two ways of getting the result of performing the operation against the domain model. In certain scenarios information is served by the controller, in others us served by the domain model. The first option can be asynchronous or synchronous but is usually synchronous.

Combining MVC with CQRS

The above combination results from scenarios where the Model in MVC is a façade as defined in [GoF]. In CQRS Controller and its View provide such façade through Command and Query objects.

The above combination results from merging the View in MVC with the View in CQRS. This can be scenario where the views of each application register with the domain model or controller. Common usages can be found in some Games with Web Interfaces that pull notifications from the server and update its interface

Concluding

There are for certain many other ways that we can compose both patterns. Especially when get into composite user interfaces as defined by the discoverer of MVC pattern, Dr. Trygve Reenskaug, in his article "MVC. It's Past and Present".

In retrospect, the similarities between both patterns maybe not be such a surprise. Amongst other things, both target solving the structural impedance mismatch between accessing information and changing information when using a domain model. Albeit each dealing with technical contexts that are quite different.

Questions and comments are most welcome.