CQRS Pattern Language

38 views
Skip to first unread message

Nuno Lopes

unread,
Aug 24, 2010, 7:16:36 PM8/24/10
to DDD/CQRS
Hi there,

This might be an over simplification but I began to notice that what
MVC is for domain objects in the context of UIs is extremely similar
to CQRS is for domain models in the wither spectrum of SOA (what an
unfortunate name).

I wrote something about this in the DDD forum to which I collected no
feed back from the experts or otherwise (http://tech.groups.yahoo.com/
group/domaindrivendesign/message/16649).

This conviction is partly driven by the MVC presentation entitled
"MVC, Past Present and Feature authored by Tregve and available here:
http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf.

I recognize a lot of his writings in CQRS. As such I took the liberty
in trying to write down a set of problem solution statements around
CQRS inspired by the presentations referred above. Here are two as a
sample:

-------------

- Command Model and Query Model Separation

Context: The domain model combines the processing of inputs and
selections.

Problem: Processing inputs and query for information require different
technical approaches to achieve optimum performance. The combination
of processing inputs and selection tend to compromise the domain model
by making it unnecessarily complex to design and evolve At stages
processing inputs can block selections and vice versa. Contributing
for application slowdown or even deadlocks. Binding UI objects to
domain objects is not always a clear cut activity.

Solution: Split the domain model into two models. One focused in
processing transactions and other focused in processing queries. It is
common for a Query Model to hold a denormalized datasets of what would
be other wise served by the domain model. Let the UI bind directly to
these datasets.

- Synchronize the Command Model and Query Models

Context: The query model holds information from one or more coomand
models ready to be selected with ultimate performance.

Problem: The query model needs to be update whenever information in
any of the command models change.

Solution: Let the Query Model register to the Command Model as being
dependent, and let the later send appropriate messages whenever it
changes as per Command execution. To this messages we call Events.

------------

Now compare the above with P-7 and P-11. Also compare P-9 with some of
Udi writing about composite UIs.

On another note the MVC pattern structure is identical to CQRS.

CQRS - MVC

Command Model - Model
Query Model - View
Command Handler/Dispatcher - Controller

If we look at how information flows in CQRS and how CQRS distributes
responsibilities between its components is quite similar to MVC.

"The controller receives input and initiates a response by making
calls on model objects. A controller accepts input from the user and
instructs the model to perform actions based on that input." - MVC

The Command Handler/Dispatcher does the same for CQRS

"The view renders the model into a form suitable for interaction,
typically a user interface element. Multiple views can exist for a
single model for different purposes." - MVC

The Query Model instead renders data in a way suitable for queries. We
can also have multiple Query Models for the same Command Model suiting
different purposes.

"The model is used to manage information and notify observers when
that information changes. The model is the domain-specific
representation of the data upon which the application operates." - MVC

This looks a lot like the command model in MVC.

Things are so similar that as a man of reason I don't believe it is by
chance. Which makes me wonder if dev tools or tools can't be built
bridging both patterns to make application faster with the benefits of
MVC in the UI and CQRS as an Enterprise Arquitectural Pattern.
Something extremely simple and coherent where information flows
between layers and network contexts in way almost transparent.

Dr. Trygve wrote about MVC:

"The top level goal was to support the user's mental model of the
relevant information space and to enable the user to inspect and edit
this information."

I wonder if this vision can be transported and extended to distributed
system with such elegancy once implemented on

It would help if a pattern language as exemplified above could be
described for CQRS. I will certainly make a post of it.

Is this anyway relevant to anyone or is it just me that find
discussing patterns at this level interesting?

Cheers,

Nuno

Nuno Lopes

unread,
Aug 25, 2010, 9:57:45 AM8/25/10
to DDD/CQRS
Hi.

I made post on my Blog about what I mean by the above. It has diagrams
comparing both patterns etc.

http://codefish21056.blogspot.com/2010/08/cqrs-mvc.html

Hopefully this way of seeing the pattern can an added value.

Cheers,

Nuno

Chris Nicola

unread,
Aug 28, 2010, 3:12:16 PM8/28/10
to DDD/CQRS
I think the similarity is that both patterns are about separating
application (or business) logic from interaction/UI logic. That
perhaps is where the similarities end, but it is still a pretty big
one. I've noticed that most software patterns seem to focus around
either encapsulation or separation of concerns (or both). CQRS and
MVC are no different in that respect.

Zan

unread,
Oct 1, 2010, 12:41:39 PM10/1/10
to DDD/CQRS
Yes I think this is very interesting. But if you recall from the GoF
patterns book, many of the design patterns were similar, if not
identical to each other. What made them different however was their
intent. As a matter of fact, in CQRS, commands and events are very
similiar. 90% of the time they are identical! But as Greg Young has
pointed out, the intent of the event (signifying that the action has
happened in the past) is what make the two different. Therefore,
although CQRS and MVC share a similar architecture, their intent is
quite different. CQRS provides separation of concerns on an wider
enterprise level whereas MVC provides "SoC" on a UI layer level. So in
that way, CQRS is MVC at an enterprise level, and MVC is CQRS at a UI
level. That is how they are one in the same ;)

On Aug 24, 6:16 pm, Nuno Lopes <nbplo...@gmail.com> wrote:
> Hi there,
>
> This might be an over simplification but I began to notice that whatMVCis for domain objects in the context of UIs is extremely similar
> to  CQRS is for domain models in the wither spectrum of SOA (what an
> unfortunate name).
>
> I wrote something about this in the DDD forum to which I collected no
> feed back from the experts or otherwise (http://tech.groups.yahoo.com/
> group/domaindrivendesign/message/16649).
>
> This conviction is partly driven by theMVCpresentation entitled
> On another note theMVCpattern structure is identical to CQRS.
>
> CQRS -MVC
>
> Command Model - Model
> Query Model - View
> Command Handler/Dispatcher - Controller
>
> If we look at how information flows in CQRS and how CQRS distributes
> responsibilities between its components is quite similar toMVC.
>
> "The controller receives input and initiates a response by making
> calls on model objects. A controller accepts input from the user and
> instructs the model to perform actions based on that input." -MVC
>
> The Command Handler/Dispatcher does the same for CQRS
>
> "The view renders the model into a form suitable for interaction,
> typically a user interface element. Multiple views can exist for a
> single model for different purposes." -MVC
>
> The Query Model instead renders data in a way suitable for queries. We
> can also have multiple Query Models for the same Command Model suiting
> different purposes.
>
> "The model is used to manage information and notify observers when
> that information changes. The model is the domain-specific
> representation of the data upon which the application operates." -MVC
>
> This looks a lot like the command model inMVC.
>
> Things are so similar that as a man of reason I don't believe it is by
> chance. Which makes me wonder if dev tools or tools can't be built
> bridging both patterns to make application faster with the benefits ofMVCin the UI and CQRS as an Enterprise Arquitectural Pattern.
Reply all
Reply to author
Forward
0 new messages