Why the MVC perspective may be of relevance to CQRS?

I got a very interesting observation regarding the last post from a person that I follow closely. His technical teachings help so many, that I guess if he comes with such an observation it must be one that a lot of people will.

The observation was that albeit both patterns are structurally comparable, the contexts where each are applied are so different in nature that similarities may be irrelevant.

As naive as it may sound here is why it may not be such case.

Although the term "structure" was used, the scope of this term is basically one of diagram structure. What may be more relevant is:

• The way each pattern distributes responsibility amongst the concepts is the same.
• The information flows amongst concepts in the same way.

In other words, the top level algorithm is the same.

If algorithms are the same, the probability of problems solved by each ending up being of the same kind is quite high. In the end of the day we are building software and few things can be more asynchronous and prone to errors then a person or group of persons interacting with the same UI.

Considering how different the play field of each pattern is, probably we are facing a singularity, a constant solution in systems design that solves a particular set of top level problems across a wide set of technical contexts. This whether the challenges is one of building an UI or a distributed system that needs to be highly scalable. This usually rises some opportunities of simplification across the board.

Within the Domain Controller take for instance the concept of Saga. The Saga pattern is a solution applicable when we identify multiple inputs that need to be treated together has a unit (all or nothing). Yet we cannot put all those inputs into a single transaction (think a complex client/server interaction with multiple calls). The Saga gives the client the illusion that is dealing with one single domain concept yet it is orchestrating several domain objects (enforcing  invariants etc). We can imagine a very large Order built over time common in procurement processes. After the transaction ends, the Saga is disposed yet the Order remains.

A similar situation we have in the UI space when dealing with editing and presenting complex sets of information that need to be treated has a unit(say a complex task such as user registration or payment). The amount of information to be collected is such that to simplify, we split the information along several screens, each capturing only a part of the information (Wizard). This problem is solved with MVC by introducing the concept of Tool. A more sophisticated tool is one of Composite Tool hence we come to the reasoning around Composite UIs (BCs etc). When the Wizard is submitted all the data collected is sent to the domain model and the Tool is then disposed.

Quite often the subject of task based UIs come along with CQRS and scalability. Generally speaking my understanding is that by aligning the design of the UI with the way information flows across CQRS participants (and vice versa) we get a system that is far more scalable while keeping the implementation recurrent and simple then we could otherwise. 

Currently I'm not at the level of decision making where were I can apply this. So to me this comparison may bring some light in explaining why such alignment may be so elegantly effective.

If everything above fails in explaining why it may be of relevance then at least it will not fail in bringing awareness on how similar both patterns are. As such we can only wonder if experiences (successes and failures) on building solutions and tools around MVC can be selectively transposed  to the environments where CQRS is of value (avoiding the pitfalls of some approaches and capitalize on success of others).

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.