CQRS is NOT a framework nor does it need one

[Dennis]

No matter how simple or easy to use, CQRS is NOT a framework/tool/
library. CQRS is a principle. CQRS is based on CQS:

“every method should either be a command that performs an action, or a
query that returns data to the caller, but not both”

CQRS extends CQS by applying the principle at a system level.
“Create 2 objects where there was previously one.” Greg Young

Because read operations are separated from write operations by
creating an object to handle each operation, using the command pattern
to handle the operations is easy enough. To apply the command pattern
no special tool is needed. Applying good container practices (even
with Unity) makes applying the command pattern via a dispatcher simple
enough. Good container practices also make it easier to apply the
decorator pattern to wrap handlers with cross cutting concerns.
Relying on .NET Reflection over good container tool is just silly.

Regarding the definition of a “CQRS Architecture” (not to be confused
with the CQRS principle) has been defined as nothing more than a
separation of write operations from read operations at a system level.
No framework can solve this domain problem. Applying CQRS thinking to
the business domain will result in separating those commands from
queries.

Keep in mind, CQRS is orthogonal to:
• Event Sourcing
• DDD (Aggregate Roots – AR, bounded contexts etc)
• messaging bus
• message queues
• NOSQL data stores (MongoDB, RavenDB, DB4O etc)

Quite simply, creating a framework tool for CQRS is like trying to
create a tool for SRP or one of the SOLID principles.

[Shawn Hinsey]

I get where this is coming from, and I don't even disagree, but I think there is a blurry line between CQRS/CQS the concept and an implementation of command processing. The former, as you point out, doesn't lend itself towards a framework any more than the visitor pattern, but the latter certainly does.

In my view, a lot of the discussion around the notion of "why are you building frameworks when this is so simple it doesn't require one" really muddies the water. If you want to build a system which relies on command processing as an embodiment of CQRS (or for any other reason), you definitely need a framework, even if it just ends up delegating to WCF, TPL, F#'s message box, or something like that. It makes no sense to reinvent command transports, dispatchers, routers, or other EIP-style messaging components necessary to support such a system over the long haul. 

Maybe the nomenclature for such a system deserves more thought.

[√iktor Ҡlang]

On Tue, Nov 15, 2011 at 11:32 PM, Shawn Hinsey <smhi...@gmail.com> wrote:

I get where this is coming from, and I don't even disagree, but I think there is a blurry line between CQRS/CQS the concept and an implementation of command processing. The former, as you point out, doesn't lend itself towards a framework any more than the visitor pattern, but the latter certainly does.

In my view, a lot of the discussion around the notion of "why are you building frameworks when this is so simple it doesn't require one" really muddies the water. If you want to build a system which relies on command processing as an embodiment of CQRS (or for any other reason), you definitely need a framework, even if it just ends up delegating to WCF, TPL, F#'s message box, or something like that. It makes no sense to reinvent command transports, dispatchers, routers, or other EIP-style messaging components necessary to support such a system over the long haul. 

Maybe the nomenclature for such a system deserves more thought.

Apache Camel
 

--
Viktor Klang

Akka Tech Lead

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

[Shawn Hinsey]

Camel is definitely the kind of thing I had in mind.

2011/11/15 √iktor Ҡlang <viktor...@gmail.com>

[Dennis]

http://www.dofactory.com/Patterns/Patterns.aspx

[Shawn Hinsey]

If this is in reply to me, I don't follow. 

On Tue, Nov 15, 2011 at 5:49 PM, Dennis <djko...@gmail.com> wrote:

http://www.dofactory.com/Patterns/Patterns.aspx

[Dennis]

Similiar to Camel but a .NET version... http://www.dofactory.com/Framework/Framework.aspx

On Nov 15, 6:00 pm, Shawn Hinsey <smhin...@gmail.com> wrote:
> If this is in reply to me, I don't follow.
>
>
>

> On Tue, Nov 15, 2011 at 5:49 PM, Dennis <djkoz...@gmail.com> wrote:
> >http://www.dofactory.com/Patterns/Patterns.aspx- Hide quoted text -
>
> - Show quoted text -

[Shawn Hinsey]

Ah, I see. For what it's worth, I think Camel's library of patterns is more interesting and covers space that one doesn't. That said, I don't have any professional experience with Camel. It'd be nice to see something similar pop up in the .NET space.

[Tom Janssens]

I called Scritchy a CQRS framework because:
- CQRS: I wrote it targetting the CQRS architecture
- framework: a framework calls your code, a lib is being called by your code

Tom

Typed on a mobile

[Tom Janssens]

I got to my PC to clarify my answer; that makes it a bit easier to type

 

Quite simply, creating a framework tool for CQRS is like trying to
create a tool for SRP or one of the SOLID principles.

I am not usually a white coat kind of guy, but this time I will accept the challenge. ;)

Let us start with the first: Scritchy is definitely a framework IMO.

I checked wikipedia (http://en.wikipedia.org/wiki/Software_framework) :

In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API).
Frameworks contain key distinguishing features that separate them from normal libraries:

1. inversion of control
 - In a framework, unlike in libraries or normal user applications, the overall program's flow of control is not dictated by the caller, but by the framework.^[1]

1. default behavior
 - A framework has a default behavior. This default behavior must actually be some useful behavior and not a series of no-ops.

1. extensibility
 - A framework can be extended by the user usually by selective overriding or specialized by user code providing specific functionality.

1. non-modifiable framework code
 - The framework code, in general, is not allowed to be modified. Users can extend the framework, but not modify its code.

To quote the first line of the rationale:

The designers of software frameworks aim to facilitate software development by allowing designers and programmers to devote their time to meeting software requirements rather than dealing with the more standard low-level details of providing a working system, thereby reducing overall development time

So, this makes me conclude that Scritchy is indeed a software framework.

Now, about the CQRS part:

I wrote the framework to enable others and myself to build an app respecting the CQRS architecture where almost every single line of code you write has business value (think lean/startup mentality).

Let us take a look again at your quote:

Quite simply, creating a framework tool for CQRS is like trying to 
create a tool for SRP or one of the SOLID principles. 

I would like to counter this quote in a metaphor: there is a difference between Lego and Playmobil. My oldest son loves Lego, and loves to build something before he can play with it. My youngest son is more of a Playmobil kind of guy: he wants to pick up a toy and just let his imagination go wild. Just because kids can build anything with Lego does not imply that we do not need Playmobil; some like to build , while others just love to get down to business asap.

Now, can you please explain to me why Scritchy is not a CQRS framework ?

[Dennis]

Just because you can create a framework doesnt mean you should. Of
course scritchy is a framework, but it doesnt make it a CQRS
framework.

scritchy (or any so-called CQRS framework) canNOT separate command
operations from the query operations in a business domain. The
separation is a domain exercise.

Just because a framework provides a mechanism to handle event sourcing
and infrastructure to publish events does NOT make it a CQRS
framework.

Event sourcing is orthogonal to CQRS. Event publishing is orthogonal
to CQRS.

That said, if your implementing a CQRS architecture style into your
solution, then you will likely want to leverage those separate
concepts. But those concepts are orthogonal to CQRS.

There are plenty of "event sourcing" frameworks out there (Jonathon
Oliver - https://github.com/joliver/EventStore ). There are plenty of
"enterprise service bus" frameworks (Udi - NServiceBus).

My community concern is the risk of watching a version of CQRS become
CQRS-lite .... the equivelant of DDD-Lite (a DDD anti-pattern).

No one is discouraging you from letting your imagination run wild. If
you want to play with playmobil toys, by all means do so. Others,
including myself, have built so-called CQRS frameworks only to realize
it was a mistake. The semantics are important. Getting the words right
is important (lessons learned from TDD to BDD).

On Nov 16, 2:08 am, Tom Janssens <d4sk...@gmail.com> wrote:
> I got to my PC to clarify my answer; that makes it a bit easier to type
>
> > Quite simply, creating a framework tool for CQRS is like trying to
> > create a tool for SRP or one of the SOLID principles.
>
> I am not usually a white coat kind of guy, but this time I will accept the
> challenge. ;)
>
> Let us start with the first: Scritchy is definitely a framework IMO.
>
> I checked wikipedia (http://en.wikipedia.org/wiki/Software_framework) :
>

> In computer programming <http://en.wikipedia.org/wiki/Computer_programming>,
>
>
>
>
>
> > a *software framework* is an abstraction<http://en.wikipedia.org/wiki/Abstraction_(computer_science)> in

> > which software providing generic functionality can be selectively changed
> > by user code, thus providing application specific software. It is a

> > collection of software libraries<http://en.wikipedia.org/wiki/Software_library> providing
> > a defined application programming interface<http://en.wikipedia.org/wiki/Application_programming_interface>

> >  (API).
> > Frameworks contain key distinguishing features that separate them from
> > normal libraries:
>

> >    1. *inversion of control<http://en.wikipedia.org/wiki/Inversion_of_control>
> >    * - In a framework, unlike in libraries or normal user applications,
> >    the overall program's flow of control<http://en.wikipedia.org/wiki/Control_flow> is
> >    not dictated by the caller, but by the framework.[1]<http://en.wikipedia.org/wiki/Software_framework#cite_note-0>
>
> >    1. *default behavior* - A framework has a default behavior. This

> >    default behavior must actually be some useful behavior and not a series of

> >    no-ops <http://en.wikipedia.org/wiki/NOP>.
>
> >    1. *extensibility <http://en.wikipedia.org/wiki/Extensibility>* - A

> >    framework can be extended by the user usually by selective overriding or
> >    specialized by user code providing specific functionality.
>

> >    1. *non-modifiable framework code* - The framework code, in general,

> >    is not allowed to be modified. Users can extend the framework, but not
> >    modify its code.
>
> > To quote the first line of the rationale:
>
> The designers of software frameworks aim to facilitate software development
>
> > by allowing designers and programmers to devote their time to meeting
> > software requirements rather than dealing with the more standard low-level
> > details of providing a working system, thereby reducing overall development
> > time
>
> So, this makes me conclude that Scritchy is indeed a software framework.
>
> Now, about the CQRS part:
> I wrote the framework to enable others and myself to build an app
> respecting the CQRS architecture where almost every single line of code you
> write has business value (think lean/startup mentality).
>
> Let us take a look again at your quote:
>
> Quite simply, creating a framework tool for CQRS is like trying to
>
> > create a tool for SRP or one of the SOLID principles.
>
> I would like to counter this quote in a metaphor: there is a difference
> between Lego and Playmobil. My oldest son loves Lego, and loves to build
> something before he can play with it. My youngest son is more of a
> Playmobil kind of guy: he wants to pick up a toy and just let his
> imagination go wild. Just because kids can build anything with Lego does
> not imply that we do not need Playmobil; some like to build , while others
> just love to get down to business asap.
>

> Now, can you please explain to me why Scritchy is not a CQRS framework ?- Hide quoted text -

[Tom Janssens]

Op woensdag 16 november 2011 15:03:55 UTC+1 schreef Dennis het volgende:

Just because you can create a framework doesnt mean you should. Of
course scritchy is a framework, but it doesnt make it a CQRS
framework.

scritchy (or any so-called CQRS framework) canNOT separate command
operations from the query operations in a business domain. The
separation is a domain exercise.

Just because a framework provides a mechanism to handle event sourcing
and infrastructure to publish events does NOT make it a CQRS
framework.

Event sourcing is orthogonal to CQRS. Event publishing is orthogonal
to CQRS.

That said, if your implementing a CQRS architecture style into your
solution, then you will likely want to leverage those separate
concepts. But those concepts are orthogonal to CQRS.

There are plenty of "event sourcing" frameworks out there (Jonathon
Oliver - https://github.com/joliver/EventStore ). There are plenty of
"enterprise service bus" frameworks (Udi - NServiceBus).

 

My community concern is the risk of watching a version of CQRS become 
CQRS-lite .... the equivelant of DDD-Lite (a DDD anti-pattern). 

 

From your explanation I would assume that a framework should somehow not allow you to use it beyond its initial intent... 

I do not intend to make Scritchy a pars pro toto for CQRS, I never claimed it was the only way to do CQRS. My only single intent is getting the CQRS architecture out of it's ivory tower, because it is IMO an elegant approach to a common problem.

Most devs I know IRL do not populate news groups looking for the latest buzz in architecture/dev concepts; they are my target audience. Selling something is about conveying a message. 

According to your opinion I would have to say:

"Scritchy is a software framework that contains an event store and a command bus, and you can use it to develop an application CQRS style."

If you would be telling this to me, you probably lost me on the first "and".

Now I will describe you an actual conversation with one of my fellow IRL devs:

- Wassup ? 

- I just published a NuGet package: Scritchy

- Scritchy ? What's that ?

- A CQRS framework

- What's CQRS ?

- It's about separating your reads and writes completely...

- What do you mean ? I already do that ?

- I will show you some example code....

...

This is my intent. That is all that matters to me. Your opinion may vary.

 

No one is discouraging you from letting your imagination run wild. If
you want to play with playmobil toys, by all means do so. Others,
including myself, have built so-called CQRS frameworks only to realize
it was a mistake. The semantics are important. Getting the words right
is important (lessons learned from TDD to BDD).

[Sarcastic mode] Alluding on the playing part, that must have required a really brilliant and creative mind. I am grateful to finally have a chat with somebody who possesses the absolute truth on life, the universe and all things semantic. [/Sarcastic mode]

[Dennis]

> From your explanation I would assume that a framework should somehow not
> allow you to use it beyond its initial intent...

Thats just a ridiculous notion.

> I do not intend to make Scritchy a pars pro toto for CQRS, I never claimed
> it was the only way to do CQRS. My only single intent is getting the CQRS
> architecture out of it's ivory tower, because it is IMO an elegant approach
> to a common problem.

CQRS is hardly in an ivory tower. No framework tool is need to
separate command from queries. Its a domain and system level problem.
Have you had an opportunity to attend any of Greg Youngs online
sessions? If not, he makes it pretty clear how simple it is to apply
and emphasizes that one does not need a framework tool.

> According to your opinion I would have to say:
>
> "Scritchy is a software framework that contains an event store and
> a command bus, and you can use it to develop an application CQRS style."

Nope, never said that nor implied it.

> > No one is discouraging you from letting your imagination run wild. If
> > you want to play with playmobil toys, by all means do so. Others,
> > including myself, have built so-called CQRS frameworks only to realize
> > it was a mistake. The semantics are important. Getting the words right
> > is important (lessons learned from TDD to BDD).
>
> [Sarcastic mode] Alluding on the playing part, that must have required a
> really brilliant and creative mind. I am grateful to finally have a chat
> with somebody who possesses the absolute truth on life, the universe and
> all things semantic. [/Sarcastic mode]
>

Sarcasm aside (I assume your originial LEGO vs Playmobil comment was
sarcastic too) , your missing my point.

To be clear, I never defined CQRS. Greg Young (and Udi) did. My intent
is to simply reiterate their definition. You can choose to redine that
message if you want, but you should probably start calling it
something different. Getting the words right is very important. Much
like TDD was never intended to be about "testing".

[Tom Janssens]

> I do not intend to make Scritchy a pars pro toto for CQRS, I never claimed
> it was the only way to do CQRS. My only single intent is getting the CQRS
> architecture out of it's ivory tower, because it is IMO an elegant approach
> to a common problem.

CQRS is hardly in an ivory tower. No framework tool is need to
separate command from queries. Its a domain and system level problem.
Have you had an opportunity to attend any of Greg Youngs online
sessions? If not, he makes it pretty clear how simple it is to apply
and emphasizes that one does not need a framework tool.

(AFAIK separating commands from queries is CQS IMO, but let us stick to the subject.)

Most of the devs I know IRL never heard about CQRS; that is the ivory tower I am talking about.

 

> According to your opinion I would have to say:
>
> "Scritchy is a software framework that contains an event store and
> a command bus, and you can use it to develop an application CQRS style."

Nope, never said that nor implied it.

Since "CQRS framework" is not a fit, what would you be your suggestion (that reveals the intent in a clear and concise manner ) ?

 

> > No one is discouraging you from letting your imagination run wild. If
> > you want to play with playmobil toys, by all means do so. Others,
> > including myself, have built so-called CQRS frameworks only to realize
> > it was a mistake. The semantics are important. Getting the words right
> > is important (lessons learned from TDD to BDD).
>
> [Sarcastic mode] Alluding on the playing part, that must have required a
> really brilliant and creative mind. I am grateful to finally have a chat
> with somebody who possesses the absolute truth on life, the universe and
> all things semantic. [/Sarcastic mode]
>

Sarcasm aside (I assume your originial LEGO vs Playmobil comment was
sarcastic too) , your missing my point.

To be clear, I never defined CQRS. Greg Young (and Udi) did. My intent
is to simply reiterate their definition. You can choose to redine that
message if you want, but you should probably start calling it
something different. Getting the words right is very important. Much
like TDD was never intended to be about "testing".

Again... semantics probably... I have never been an expert in theories/semantics, I am more of a pragmatist; if my attempt for a description conveys the message, I am satisfied. When I find a better way to do it, or someone else suggests one acceptable to me ( N=1 ), it will be even more satisfying... 

[Dennis]

> (AFAIK separating commands from queries is CQS IMO, but let us stick to the
> subject.)

That is the subject. CQS is defined at the method level (Bertrand
Meyer). CQRS is about separating those read vs write operations at the
object level and at the system level (Greg Yound and Udi).

> Most of the devs I know IRL never heard about CQRS; that is the ivory tower
> I am talking about.

Just because they never heard about CQRS doesnt mean its in an ivory
tower. I sure hope the CQRS community is NOT being viewed as an
"disconnected from the practical concerns of everyday life" (Ivory
tower).

> Since "CQRS framework" is not a fit, what would you be your suggestion
> (that reveals the intent in a clear and concise manner ) ?

There isn't one. however, one would probably use the following in
there solution:
* An event sourcing framework
* A service bus framework
* A message queue framework
* Command pattern to handle the commands(writes)
* etc

CQRS itself is a domain/system concern. CQRS strikes to the heart of
SRP.

[Kalle Launiala]

I don't mean to derail this, but I had to post, because of the very
reasons that frameworks and libraries cause an issue.

Frameworks and libraries require some contracts of how to use them.
This implicitly causes dependencies; regardless of how minimal the
common point is agreed.

CQRS as a "design model" allows massively scalable applications with
clear design distinction between different areas of logic. Going cross-
platform (that is actually one strong points in high-distributed and
scalable environments) makes any framework and library add complexity
and constrain the use of "best-partial frameworks" such as event-
sourcing, service-bus and so forth.

We have demonstrated model + code-generation approach that has none of
the constraints that frameworks and libraries introduce. Being simple
and mainstream-usable, I'd go even as far as to challenge any
framework.

It allows combining the "best-framework-for-the-place" that is for ES,
service-bus, message queue... properly made even allows changing the
back-end framework without hand-written code needing to change at all.

In the CQRS demonstration the client-server service calls are made
without any joined framework/library in between for proxy-object-
serialization-deserialization. Yet the implementation is much cleaner
technically simpler and very likely faster than any framework would
achieve.

Not only that, if something bothers in inefficient generator, one can
simply enhance it afterwards. Doing it with framework/library raises
almost certainly compatibility-refactoring issues.


Kalle

[Dennis]

Your right... your derailing the convo.

I am not calling frameworks bad or evil. However, I would say if we
are describing "code generation" as a solution to CQRS, we are
probably way off basis.

> > SRP.- Hide quoted text -

[Nuno Lopes]

My Take on this is that CQRS needs as much a framework as does MVC. It really depends on what you want to do.

There is a difference between CQS and CQRS. Trying to equate the two at the same level does not make much sense to me. What kind of programming principle is there in having a model for reads distinct from a model for writes? For one, it breaks the abstraction principle and DRY. So this principles are replaced by something else, what else? I would say, availability and performance.

Cheers,

Nuno

[Joshua Ramirez]

Semantics seems to often be at the heart of these discussions. While the immediate question of a CQRS framework's validity seems the most pertinent, it is irrelevant if the semantics of the framework are not well defined. In the interest of learning more from this discussion I'd like to highlight the major points in this tread. Arguably, both of your points are correct, from your own perspectives. I'm intuiting that Dennis does not want a prescribed implementation for all of CQRS-as-a-way-of-thinking. And I agree. Tom does want that either, and I think he'd agree. Tom wants a chosen implementation of CQRS thinking, for practical reasons under specific circumstances, replete with design trade-offs acknowledged as framework. Perhaps Tom would agree with my ignorant oversimplification of his hard work. So, agreeing on these observations, we're left with an understanding that the framework is a specific architecture whose constiuent parts represent the embodiment of CQRS thinking. Architecture, as we all know, has attributes. It is these attributes which I perceive to be the most pertinent semantics for these types of conversations. Suggesting that the validity of a persons hard work as irrelevant in the domain to which it exists is quite a harsh judgement. However, that doesn't invalidate Dennis' concerns over the repercussions of over-frameworkizing a design theory. Perhaps that doesn't even hit his concern exactly. In any case, and in conclusion, I'm left with 3 major observations. First, if a framework is made, its attributes with regard to its chosen tradeoffs in implementation should be well discussed in a CQRS discussion domain. Second, CQRS is agreeably not a prescribed implementation. Third, A chosen CQRS implementation frameworkized into a package certainly is a valuable learning tool for kinetic, tactile developers, provided that the implementation is clearly labeled as one of many, many, possible implementations.

[Dennis]

" Suggesting that the validity of a persons hard work as irrelevant in
the domain to which it exists is quite a harsh judgement."

I never said that. On the contrary, if we are referring to scritchy,
there has been a significant amount of churn on that project. That
said, it is being submitted to the public domain for feedback. I've
provided that feedback. In the bigger scope of things, this should be
seen as valuable.

Ultimately, are we talking about CQRS as a principle or an
architectural approach that includes Event Sourcing, Event publishing,
etc etc. Again, the later are orthogonal to CQRS.

CQS and CQRS are different. CQS deals with methods. CQRS addresses the
separation at the object and system level. CQRS by itself does NOT
include event sourcing, event publishing etc.

Greg or Udi ... care to weigh in?


On Nov 16, 2:49 pm, Joshua Ramirez <joshuaramirezdevelo...@gmail.com>
wrote:

[Tom Janssens]

Thank you Joshua, I think you summed it up pretty well. As I assume the added value of this conversation is really small I will call it a day, and invest my time in other things...

[Dennis]

"There is a difference between CQS and CQRS. Trying to equate the two
at the same level does not make much sense to me. "

I'm certain I have NOT done that. They are different. CQS deals with
the separation at the method level. CQRS deals with the separation at
the object level. " There are 2 objects where there was one" Greg
Young.

CQRS does not include event sourcing and event publishing. that said,
I would choose to use both when applying CQRS in a system.

> > create a tool for SRP or one of the SOLID principles.- Hide quoted text -

[Dennis]

"What kind of programming principle is there in having a model for
reads distinct from a model for writes? For one, it breaks the
abstraction principle and DRY. So this principles are replaced by
something else, what else? I would say, availability and performance."

CQRS addresses this concern. When CQRS is applied there is NOT "one
model to rule them all". The model on the write(command) side is
focused on behavior. the model on the query(read) side is for
reporting and display. CQRS directly addresses availability and
performance by applying the http://en.wikipedia.org/wiki/CAP_theorem.
The write side is focused on CA and is relaxed on partionability. The
read side is focused on AP and is relaxed on consistency.

On Nov 16, 2:06 pm, Nuno Lopes <nbplo...@gmail.com> wrote:

[Sharas]

My impression is also that CQRS takes away some model expressiveness but adds some technical benefits. So it's more like a trade off.

In CQS queries are expressed coherently with semantics of the object. In CQRS there's a notion that read side that can be denormalized in any way you like. With this you add complexity or messiness of your model. Yes, storage is cheap, but that's not the issue, I want to make sense of my data in terms of my model.

[Joshua Ramirez]

Dennis,

For the record, I should think that the community finds your zeal for the purity of the design concepts to be commendable. Seems that you hit it on the nail by asking what we are talking about; CQRS as a concept or as an architecture. It would be unfortunate to have CQRS popularized as an overloaded term which inadvertantly includes other, "orthogonal", patterns such as event sourcing, for example.

I get the sense that you want to keep things separate, as their conceptual nature implies. So, for naming a framework, perhaps one should think of giving the entire solution a proper name. I immediately think of frameworks named like Spring, and Sharp. They're a combination of technologies and patterns.

[Glenn Block]

agreed. The challenge of CQRS is not lack of tools / fwks. It is
understanding the patterns and how to apply them and when to apply
them. Once you understand then you can see about simplifying recurring
patterns.

Sent from my Windows Phone
From: Dennis
Sent: 11/15/2011 5:24 PM
To: DDD/CQRS
Subject: [DDD/CQRS] CQRS is NOT a framework nor does it need one

[Nuno Lopes]

Hi Denis,

All I wanted to say is that the principles are not in CQRS but within DDD. CQRS its just a pattern much as MVC is. Your could understand CQRS but never get into the principles of DDD. Indeed, CQRS is talked about outside the cope of DDD up into SOA, using other principles.

CQS deals with
the separation at the method level. CQRS deals with the separation at

the object level. " There are 2 objects where there was one" Greg
Young.

I think a lot of us know that. What I was saying is that CQRS should not be equated as a matter of design principles rather then a pattern that leads to a specific class of solutions to a specific class of problems.

I think the problem of this thread for me is that it started with a "problem" that is non existent in my context. You see, MVC is not a framework either, yet a lot of frameworks are built using it. So starting with a statement that "CQRS is not a framework!" is focusing on the wrong thing. Of course it is not! Yet it does mean that frameworks can't be developed translated the Pattern to specific technical contexts.

Cheers,

Nuno

[Nuno Lopes]

Just a final note.

IMHO, the concerns around CAP are embodied in the entire DDD as a theory of design.

Just look at the problem statement around the Aggregate pattern. Two distinct Aggregates can be potentially eventually consistent with each other. The "trick" is remove eventually consistency at this level is by understanding that the set of facts maintained by each do not overlap (DRY).

Cheers,

Nuno

On Nov 16, 2011, at 9:28 PM, Dennis wrote:

[Tom Janssens]

One last blurb: IMO there is a difference between "CQRS is not a framework" vs "This is a CQRS framework"; I think both can be true.

On CQS vs CQRS: CQRS is just a subset of CQS, as it adds an extra requirement (cfr. all eagles are birds but not all birds are eagles).

That's all folks! Nothing to see here... Please move along... ;)

[Dennis]

> All I wanted to say is that the principles are not in CQRS but within DDD. CQRS its just a pattern much as MVC is. Your could understand CQRS but never get into the principles of DDD. Indeed, CQRS is talked about outside the cope of DDD up into SOA, using other principles.

DDD is orthogonal to CQRS. CQRS is its own principle. Again,
separation of read vs writes at the object level (rather than method
level - CQS). at its heart addresses SRP much like MVC. However,
there is no prescribed way to handle "how" to separate those reads vs
writes. That is a domain concern and domain exercise. This is why this
forum broke away from the DDD user group.

MVC is a defined pattern. Out of MVC multiple flavors have emerged
with small caveats ... Supervising Controller, Passive View, MVVM
(presentation model). Do I need a framework for MVC? Of course not.
But.. FubuMVC sure made ASP.NET web development easier.

My primary point is CQRS is way of thinking about the domain (much
like DDD). If I apply CQRS at the domain, teams will likely want to
compliment their CQRS thinking by leveraging:
* DDD thinking
* Event sourcing
* EDA - event driven architecture
* etc

> What I was saying is that CQRS should not be equated as a matter of design principles rather then a pattern that leads to a specific class of solutions to a specific class of problems.

If thats true, what patterns are specifically CQRS?

> ...So starting with a statement that "CQRS is not a framework!" is focusing on the wrong thing. Of course it is not!

Several on this forum have made it clear they disagree this statement.
Which is why I decided to speak up. That said, if you assume CQRS
includes things like ES, Event publishing, etc. then yes you will
likely create a framework. However, CQRS is principle to guide us how
we think about the domain. Separating commands and queries is a domain
exercise.

[Dennis]

the "CQRS is not a framework nor does it need one" was obviously meant
to get the attention of this community. Of course CQRS is not a
framework. Where I believe the community is potentionally amiss is
when we assume CQRS is also DDD, Event sourcing, event publishing
etc.

Other than commands and queries being separated into objects at the
domain, what else can CQRS really claim to be specific to CQRS?

[Nuno Lopes]

Hi,

My primary point is CQRS is way of thinking about the domain (much
like DDD).

Could you point then an example where applying CQRS induces a way of thinking distinct from DDD?

Cheers,

Nuno

[Greg Young]

Aggregates only hold state involved in invariants.

[Nuno Lopes]

Hi,

Aggregates only hold state involved in invariants.

Yes and? How does that provide a distinct way of thinking or designing? Should it matter where state is stored to make an effective domain model in terms what is the interface of an Aggregate? Or is it internal choice?

If is is not an internal choice, say changing an address where no specific invariants at a time are found. Is the query model in CQRS handling use cases / commands by itself now? If that is the case, how is that done considering that it is a denormalized projection? How is the concept of Entity maintained in those cases?

Do we have separate sets of commands now. A set of commands where invariants are concerned that are sent to the domain model and a set of commands where there are no invariants with exception of type as such are sent to views? 

What about CQRS events, aren't they a form of domain events? Don't they belong to the domain model even if not stored?

Cheers,

Nuno

[Dennis]

So your answering my question with a question.

"Could you point then an example where applying CQRS induces a way of
thinking distinct from DDD? "

* Explicit separation of commands from queries. Its a domain exercise,
not a coding exercise.
* More of focus on messages (commands, events & queries)

I'll ask again:
What else can CQRS really claim to be specific to CQRS?

Event sourcing, DDD etc are orthogonal. Those things compliment a
solution based upon CQRS thinking.

[andho]

If the writing code according to how code is to be written for the framework, ensures that Command and Queries are separated, then yes the Framework is a CQRS Framework, because it ensures the code written adheres to the CQRS principle. I don't think anybody said that CQRS itself is a framework.

I am not saying CQRS needs a framework or not, or even if a framework would be EVIL. Now we all know that a Framework can be misused, for example a naive developer might use an MVC framework but put a lot of Business Logic inside the Views.

[Dennis]

Ensuring commands and queries are separted is a domain exercise. A
framework cannot do that for you. A framework might provide the
abstractions, but having a class inherit from an ICommand or IQuery or
IEvent or AggregateRoot base abstraction is not CQRS. Furthermore, a
framework is simply not needed for something that basic.

[jdn]

Out of curiosity, is there a point to any of this? Seems like a lot
of repetition with no added substance.

jdn

[Tom Janssens]

Yes, absolutely: http://xkcd.com/386/

[Dennis]

The substance is to help the community. Stop making CQRS more than
what it is. Individuals assume they are doing CQRS if they are doing
event sourcing, etc.

If its sounds like repition its because the message is same. Others
are just framing their remarks slightly different but it still comes
back to the fundamental point: CQRS is a way of approaching a domain
and its system by separating the commands from queries.

The challenge is still out there to the community... what else does
CQRS include?

> > > inside the Views.- Hide quoted text -

[Nuno Lopes]

Hi,

I'll try to put some substance on my side of equation.

Il'll try to clearly tell the group what I mean when I say that DDD is key to CQRS, and neither I consider CQRS a theory on its own. I'll do it with an example.

* Explicit separation of commands from queries. Its a domain exercise,
not a coding exercise.

Where does DDD advocate that such separation shouldn't be explicit? Isn't that what CQS is all about at the object level? Why would DDD say differently at a higher scale (Bounded Context)?

* More of focus on messages (commands, events & queries)

What does that mean? 

If you ever worked with a good domain modeler / designer, most of the methods you see in entities within a domain model are mutators along with some attributes (the ones that are core). Some do calculations, but you see getters as core. On the other hand a lot of entities you see in a matured domain model embody long running business operations (PurchaseOrder, PaymentOrder, ShippingOrder, SoundAlarmOrder, StudentExamination, etc).. For instance, the result of a PaymentOrder is a "Payment Receipt" (projection of a successful PaymentOrder). We know that these entities are crucial. A domain model full of things (Product, Catalogue, Car,  Person, etc) is a sign of immaturity or CRUD. Roles are also crucial.

When a group talks about CQRS,  scalability is the order of the day. Indeed scalability does affect the design of a domain model and its quite natural it does. Business people know this for decades so much that they are used to process reengineering due to problems of scale. Only the IT people seams to be unaware of these matters until CQRS came to town?

Here is an example of how scalability may affect ones domain model:

Take a thread and its posts and an invariant stating that if a thread is closed no further post should be allowed in. There are many ways one can do this.

We can put a Post and Thread in the same Aggregate having the later as the AR. 

class Thread {

...

Close(...);

Post(Message,....);

}

If the use case Submit Post to a Thread needs to scale to thousands a second in peak our then this approach will no scale that well since all posts will be serialized and run by one processor. Yet it might go really far still using queues. 

But if that is not enough, taking some lessons from the domain we might decide for two Aggregates:

1) Relax the rule. That is, even if the thread is close at time t we might let in posts for a few seconds more. 

class Thread {

...

Close(...);

}

class Message {

...

Post(threadId, threadStatus, ....); // if thread status is closed the post operation fails.

}

In this case threadId and threadStatus can be obtained from the view, but views must be up to date according to some SLA. If the view updates are dragging or there is a failure in the link, the SLA will broken yet still messages are coming in. Some ad-hoc cleaning is needed (or some "cleaner" process can be kicked). Granted this is a but messy but its an option.

2) Maintain the rule and integrate a long running business operation and use compensation (I like this more). If no compensation can be devises it also easy to fix.

class Thread {

...

Close(...);

AcceptPost(postId, postStatus);

Handle(PostSubmitted ....);

}

class Post {

submittedOn ...

...

Submit(...);

Accept(...);

Cancel(...); 

Handle(ThreadAcceptedPost, ....) 

.... some time out cancels the order. This a long running business process that occurs in stages (submitted, accept or cancel). Some texts call it Saga, other Transactions, other Moment-Intervals ...

}

class Message {

...

Publish(....); 

Remove(....);

Handle(PostOrderSubmitted ....); // Publishes the message

Handle(PostOrderCanceled ); // "Removes" the message

}

Model: http://yuml.me/59c9d6f9

Since there is a one to one conceptual relationship we could blend Post and Message together. Granted it would violated SRP, but hey but where are talking a one to one relationship where none of the parts involved are genuinely optional so it might not be such a bad option. We would need to look at other use cases.

The thread Accepting a Post and Publish the message are parallel tasks in this workflow. It is done this way because Threads rarely reject posts.

As you can see having separate command model and query model is a bit irrelevant! Yes we can use a view model to structure information for performance or presentation, to not to clutter the domain model with query concerns, you can have views served to OLAP systems, or use views to serve has cache form remote clients, but that is orthogonal do the domain model and in particular to the algorithm, that just it IMHO. 

For instance probably I would choose to have PostOrder and Post deployed together in some high performance cluster so to to speed up processing. And since closing a thread does not happen that often probably a slower server would be more the enough to cope with peak times.

On a matter of deployment the greatest impact would be on the messaging scheme of choice. If objects these objects are distributed can we use Web Services to transport messages? What about messaging reliability, how the lack of it affect the system, say too many time outs on our posts? Shouldn't we use durable messaging or can we use ES to recover from messaging failures on the event side? How about a Messaging Bus, wouldn't this more manageable with it?

Look, I dig a model for Queries and a model for Transactions (Commands), i've written some stuff about it, it is nevertheless my opinion that it does not really bring anything more to DDD in terms of letting our designs be driven by our domains. This is crucial, otherwise DDD is just a nonsensical acronym.

Now ES in Greg's sense it is my view that introduces something different to the table in terms letting our designs be driven by the domain. His events aren't just messages, they embody atomic facts in a time line over which we can reason, make projections (derive facts) and computations. If I was to make a suggestion, that indeed introduces a slight different way logically designing the problem domain while adding expressiveness amongst other things. This can be observed in our tests. It does not overrule prior art, it augments it.

I think the question to the CQRS "crowd" is "Why let our designs be driven by the domain and what does it mean to them?" "What to you gain by not letting?". Is it because it scales better? Does the Saga Pattern, Reservation Pattern and so on help in understanding the domain or is it the other way around? Why does it handle better CAP issues?

Cheers,

Nuno

[Nuno Lopes]

Errata on my latest post:

I wrote:

"If you ever worked with a good domain modeler / designer, most of the methods you see in entities within a domain model are mutators along with some attributes (the ones that are core). Some do calculations, but you see getters as core."

Instead should be:

If you ever worked with a good domain modeler / designer, most of the methods you see in entities within a domain model are mutators along with some attributes (the ones that are core). Some do calculations, but you don't see getters when you take a core view of it.

[jdn]

I don't see how it helps but YMMV.

jdn

[jdn]

Here's Greg quotation #1:

"Many people have been getting confused over what CQRS is. They look
at CQRS as being an architecture; it is not. CQRS is a very simple
pattern that enables many opportunities for architecture that may
otherwise not exist. CQRS is not eventual consistency, it is not
eventing, it is not messaging, it is not having separated models for
reading and writing, nor is it using event sourcing"

However, here is Greg quotation #2:

"Somewhat recently –I have not been blogging much I know— Udi put up a
good post (and long) about Command and Query Responsibility
Segregation. One point that Udi brought up is that people have tied
together Event Sourcing and Command and Query Separation. They are
certainly two different patterns but I believe that it is a relatively
rare case where two patterns share a symbiotic relationship."

You seem to be harping on the one, other people are talking more about
the other. Random challenges to the community
accomplishes........can't think of anything.

jdn

On Nov 17, 2:52 pm, Dennis <djkoz...@gmail.com> wrote:

[Dennis]

@Tom: you are welcome to stop participating. I serious doubt you
intend to discredit these same points already made Greg and Udi... and
others who have pioneered the ideas around CQRS. That said, perhaps
your participation would be more valuable if framed the definition of
CQRS for us.


On Nov 17, 1:26 pm, Tom Janssens <d4sk...@gmail.com> wrote:
> Yes, absolutely:http://xkcd.com/386/

[Dennis]

Im actually harping on both.

And yes.. the "challenge" part was probably a little off color... this
discussion is obviously getting redundant.

> > > - Show quoted text -- Hide quoted text -

[Dennis]

> Il'll try to clearly tell the group what I mean when I say that DDD is key to CQRS...

CQRS without DDD would not be as valuable. However, I can apply CQRS
without applying DDD.

> Where does DDD advocate that such separation shouldn't be explicit? Isn't that what CQS is all about at the object level? Why would DDD say differently at a higher scale (Bounded Context)?

No CQS deals with the separation of method into 2 methods to separate
a command and query operation. CQRS deals with the separation of
commands and queries into their own objects.

> > * More of focus on messages (commands, events & queries)
>
> What does that mean?

When CQRS is applied at the system level, messages are important part
of the separation.

I'm pondering the rest of what you said... but I interpreted what you
were saying on the surface as being directly related to DDD and not
CQRS. The scalability part I agree. But see that as a side effect of
separating the system into commands(behaviour model) and queries
(reporting model).

[Nuno Lopes]

if that is the case then ok. But it seams that you argued that CQRS is much more then a simple pattern.

You talked about it being something different to DDD with its own set of principles and practices. Something I never heard none of them stating.

Sent from my iPhone

[Dennis]

CQRS is its own principle. I disagree (repeating) that CQRS is a
pattern. CQRS is a principle. Its orthogonal to DDD, ES, EDA etc

individuals seem to be encompassing CQRS to mean you are doing ES,
DDD etc. Those things compliment each other but they are not necessary
to apply CQRS.

@jdn... this exactly why I'm repeating the same message.

On Nov 17, 4:37 pm, Nuno Lopes <nbplo...@gmail.com> wrote:
> if that is the case then ok.  But it seams that you argued that CQRS is much more then a simple pattern.
>
> You talked about it being something different to DDD with its own set of principles and practices. Something I never heard none of them stating.
>
> Sent from my iPhone
>

[Dennis]

.... and yes... the CQRS principle is a simple concept. The complexity
is in the business domain.

On Nov 17, 4:37 pm, Nuno Lopes <nbplo...@gmail.com> wrote:

> if that is the case then ok.  But it seams that you argued that CQRS is much more then a simple pattern.
>
> You talked about it being something different to DDD with its own set of principles and practices. Something I never heard none of them stating.
>
> Sent from my iPhone
>

[Nuno Lopes]

That is the side effect of using Aggregates not if separating models. It was the Aggregates and the use case that made a method turn into an entity representing a long running business process.

And yes, one can use CQRS without DDD. It has been for a long time.

Udi says it quite clearly. One use case, one command, one Aggregate method, one transaction. At least he used to.

If you find that you need more then one transaction to perform a use case, then one is missing some concepts.

If you find that multiple use cases are interfering with each other to the point where an Aggregate becomes unusable the transaction boundary needs to be reduced. Hence you may need an Aggregate that captures that specific use case and capture the transaction as a long running business process.

You keep on doing in the drum-buffer-rope of design protecting the weakest links as they are found during performance testing. Otherwise you may end up with feeling the pipe with excessive inter aggregate messaging. This might be or not a problem depending on the network infrastructure.

Sent from my iPhone

[Nuno Lopes]

Greg calls it a pattern not a principle. Patterns and principles are distinct animals.

Sent from my iPhone

[jdn]

Greg calls it a pattern.

CQRS has symbiotic relationships to Event Sourcing, etc.

One can say that pure/strict is 'only' a pattern/principle. Many
have.

You can also say that when you build systems around the CQRS pattern/
principle, you will almost always tend to create something like a
framework to help implement it. Is it, in some sense, incorrect to
point to the implementation and say "that is CQRS"? Strictly
speaking, yes.

But no one is going to stop doing it, since it is easier to say than
"A framework that is inspired by CQRS and encompasses its natural
symbiotic relationships."

I write code that uses the CQRS pattern/principle, but I sometimes let
my commands return a value. So am I really using it?

I don't see anything new here. YMMV.


jdn

[Dennis]

@Glenn What patterns do you see as being specific to CQRS?

On Nov 17, 1:10 am, Glenn Block <glenn.bl...@gmail.com> wrote:
> agreed. The challenge of CQRS is not lack of tools / fwks. It is
> understanding the patterns and how to apply them and when to apply
> them. Once you understand then you can see about simplifying recurring
> patterns.
>
> Sent from my Windows Phone
> From: Dennis
> Sent: 11/15/2011 5:24 PM
> To: DDD/CQRS
> Subject: [DDD/CQRS] CQRS is NOT a framework nor does it need one
> No matter how simple or easy to use, CQRS is NOT a framework/tool/
> library. CQRS is a principle. CQRS is based on CQS:
>
> “every method should either be a command that performs an action, or a
> query that returns data to the caller, but not both”
>
> CQRS extends CQS by applying the principle at a system level.
> “Create 2 objects where there was previously one.” Greg Young
>
> Because read operations are separated from write operations by
> creating an object to handle each operation, using the command pattern
> to handle the operations is easy enough. To apply the command pattern
> no special tool is needed. Applying good container practices (even
> with Unity) makes applying the command pattern via a dispatcher simple
> enough. Good container practices also make it easier to apply the
> decorator pattern to wrap handlers with cross cutting concerns.
> Relying on .NET Reflection over good container tool is just silly.
>
> Regarding the definition of a “CQRS Architecture” (not to be confused
> with the CQRS principle) has been defined as nothing more than a
> separation of write operations from read operations at a system level.
> No framework can solve this domain problem. Applying CQRS thinking to
> the business domain will result in separating those commands from
> queries.
>
> Keep in mind, CQRS is orthogonal to:
> •     Event Sourcing
> •     DDD (Aggregate Roots – AR, bounded contexts etc)
> •     messaging bus
> •     message queues
> •     NOSQL data stores (MongoDB, RavenDB, DB4O etc)
>
> Quite simply, creating a framework tool for CQRS is like trying to
> create a tool for SRP or one of the SOLID principles.

[Dennis]

Well said.

I still disagree its a pattern though. Other than the basic command
pattern ... how else would you apply CQRS?

[Dennis]

Seems odd we would refer to it as pattern since CQS itself is a
princple. CQRS is an extension of that princple. Also, its much more
natural to talk with domain experts about the behavior(commands) and
the views(queries) they want to see rather than the pattern I used to
implement the domain knowledge. When applying CQRS I would use the
command pattern (i have yet see any other approach).

Personally, I create a separate message for the command and associate
it with a single handler.
For queries, I create a separate message and associate it with a
single handler that outputs a specific result.

That said, I could easily violate CQRS (as a principle) by introducing
behaviour in the query handler.

On Nov 17, 5:01 pm, Nuno Lopes <nbplo...@gmail.com> wrote:
> Greg calls it a pattern not a principle. Patterns and principles are distinct animals.
>
> Sent from my iPhone
>

[Dennis]

Seems odd to me since CQS is referred to as a principle. CQRS is CQS
applied by creating 2 separate objects. As a principle, its natural to
interact with domain experts an express their domain as
behavior(commands) and the views they want to see(queries). This has
nothing to do with a pattern. When I code this separation, I would be
inclined to apply the command pattern for each message.

Personally, I separate the command objects and associate them with a
single command handler than returns void.

For queries, I create a query object that has a specific handler that
returns a specific output(view/report).

I could easily violate the CQRS principle by logically adding
"behavior" to my query handlers.

On Nov 17, 5:01 pm, Nuno Lopes <nbplo...@gmail.com> wrote:
> Greg calls it a pattern not a principle. Patterns and principles are distinct animals.
>
> Sent from my iPhone
>

[jdn]

Let me answer your question with a question (yes, I know that is
annoying). Two, actually.

How would you define the difference between a pattern and a principle?

Depending on how you answer that question, what do you think is
important in determining whether to call CQRS one or the other? Is
there some additional confusion that you think needs to be cleared up,
as opposed to the (now, I believe, thoroughly examined) potential
confusion regarding conflating pure/strict CQRS with symbiotic CQRS?

Okay, technically, that's three questions.

jdn

[Nuno Lopes]

Hi Danny,

CQRS is its own principle. I disagree (repeating) that CQRS is a
pattern. CQRS is a principle. Its orthogonal to DDD, ES, EDA etc

Seems odd to me since CQS is referred to as a principle. 

No it is not. It is often referred has a pattern by both. A recurring solution for a specific set of problems. Indeed it is usually mixed with other architectural patterns, including the ones where one has one single model doing queries and commands.

Honestly Danny, I'm not following you. You keep on telling us that its a principle yet the same people leading the CQRS bandwagon say its a pattern, in particular Greg and Udi. Udi even writes:

"Although some proponents of CQRS have stated that it can and should be used as the top-most architectural pattern, both myself and Greg Young (arguably the first two to talk about it and the two who ultimately collaborated on naming it – and now Google knows we didn’t means “cars”) always recommended it as a pattern to be used one level down."

Im actually harping on both.

Don't think so on that matter.

Referring to DDD and ES you say:

Those things compliment each other but they are not necessary
to apply CQRS.

DDD is a practice. ES its a pattern. On CQRS its a Pattern. Both are used in the DDD practice.

Honestly Danny, I'm not following you. You keep on telling us that its a principle yet the same people leading the CQRS bandwagon say its a pattern. 

Are you stating what CQRS is or what is according to your understanding.

Unless they changed their minds, It is ok to disagree with anyone, yet if you do you need to back it up with some consistency and more substance then what you have done until now. Apart from that anyone can make mistakes. I've done some in the course in my own time.

individuals seem to be encompassing CQRS to mean you are doing  ES

Which ones? Generally speaking we do not. Nevertheless a lot of presentations talk about CQRS, ES and both together, may be that is confusing you. A lot of questions concern both together.

Cheers,

Nuno

[Dennis]

> No it is not. It is often referred has a pattern by both. A recurring solution for a specific set of problems. Indeed it is usually mixed with other architectural patterns, including the ones where one has one single model doing queries and commands.

Nothing wrong with disagreeing. On this point, I disagree with both.
CQRS is being mixed with other architectural patterns but those
patterns are already well defined. Those patterns are orthogonal to
CQRS. For example, ES is not required to apply CQRS. The minimum
requirement is to apply the displine of separating commands from
queries.

> "Although some proponents of CQRS have stated that it can and should be used as the top-most architectural pattern, both myself and Greg Young (arguably the first two to talk about it and the two who ultimately collaborated on naming it – and now Google knows we didn’t means “cars”) always recommended it as a pattern to be used one level down."

NOTE: CQRS is being discussed as an "architectural pattern". Consider
this... If I build build a system that includes a component that only
handles commands, a separate component that only handles queries and
those components live on separate servers and run in different
processes, have I satisfied the minimum for CQRS architecture? I say
yes. So, what is the pattern? How is separating the reads from the
writes a pattern? Because I was disciplined around the principle of
CQRS I am able to easily partion the system. The other stuff, ES, EDA
and service bus stuff obviously adds significant value.

> DDD is a practice. ES its a pattern. On CQRS its a Pattern. Both are used in the DDD practice.

Again I disagree CQRS is pattern. The guidance for DDD for the MOST
part has not changed since CQRS has come along. However, because of
CQRS, I tend view AR's more favorably in light of Greg Young
emphasizing no getter or setters .. behavior only.

> Are you stating what CQRS is or what is according to your understanding.

Both. That said, application (real world experience) is a great
teacher.

> yet if you do you need to back it up with some consistency and more substance then what you have done until now. Apart from that anyone can make mistakes. I've done some in the course in my own time.

How have I been inconsistent? ... and then Ill respond to the latter
part of that statement

> > individuals seem to be encompassing CQRS to mean you are doing  ES Which ones?

yeah... I dont do that... ie point fingers. Public record speaks to
this on its own. Besides how is that constructive? So if I dont
specify names, does that make it untrue? Just because your not hearing
people describe CQRS in this context does not mean its not happening.

[Dennis]

@jdn... google group issues... original response appears to have
disappeared. going to wait before I try re-replying.

> > > jdn- Hide quoted text -

[Dennis]

A principle is a law/rule that has to be followed. A principle
requires discipline. SOLID. The discipline is often times applied more
effeciently by devs who are seeking to following the discipline. In
the case of CQRS, the separation of command and queries is at the
heart of CQRS. If commands and queries are not separated, then CQRS is
not being applied. Much like if I have method that is performing 5
different operations, Im likely violating the rule of the SRP
principle.

A pattern is a reusable solution to a common problem. Obviously GOF&
architectural patterns come to mind. The patterns I might use when
applying CQRS is the command pattern, event sourcing, service bus etc.

I believe it is important to establish CQRS as princple. If you do not
first separate command and query operations as objects, then you are
not adhering to the CQRS discipline. The other things ES, service bus
are already well defined patterns exclusive of CQRS.

In regards to pure/strict CQRS vs symbiotic CQRS, I get what you are
saying. Previously you said

"I write code that uses the CQRS pattern/principle, but I sometimes
let
my commands return a value. So am I really using it? "

This is where the discipline of any princple comes into play.
Obviously a bunch of factors weigh into the decision to intentionl or
unintentional violate any princple.

On Nov 17, 7:05 pm, jdn <jdnjdn...@gmail.com> wrote:

> > > jdn- Hide quoted text -

[Nuno Lopes]

Hi Denis,

To cut a long story short and avoiding the semantics around what is a principle or a pattern.

If CQRS stated that: "Every object should not have methods changing state and methods returning data"!

This would be a principle.

Now CQRS is not described like that. Sorry. But is not.

At the model level if a there was a CQRS principle it would be: "Every model should not have objects changing state and objects returning data"!

Again its is not described like that.

I don't have the time now to go deeper why it is not described like that. To put it succinctly:

CQRS was born out of a very common problem. The impedance mismatch between the object structures necessary to process data efficiently and the object structures necessary to query / observe data efficiently. I've posted awhile ago about the driving forces of CQRS in my context.

Cheers,

Nuno

[Nuno Lopes]

Or better:

If there was a CQRS principle it would be something like this:

At the object level

"Every object should either have methods that return data or change state, not both"!

At the model level

"Every model should either have objects that return data or that change state, not both"!

CQRS is not described like that in any way since many people would probably disagree, myself included. This because it rises problems that are beyond the scope of this thread. Instead it is described as a Pattern solving a particular set of problems. One important one I described in the previous post.

Cheers,

Nuno

[Dennis]

> If CQRS stated that: "Every object should not have methods changing state and methods returning data"!

> At the model level if a there was a CQRS principle it would be: "Every model should not have objects changing state and objects returning data"!

Nothing Ive said implies either statement. The current definition is
about "separating". That separation is a subjective rule based upon
discipline of that rule. The separation is first and foremost a domain
exercise NOT a coding exercise.

Seriously, how is separating command/query operations into objects a
pattern? Is that pattern similiar to a GOF or architectural pattern?

> CQRS was born out of a very common problem. The impedance mismatch between the object structures necessary to process data efficiently and the object structures necessary to query / observe data efficiently. I've posted awhile ago about the driving forces of CQRS in my context.

yes i agree that is an important aspect. There are many more benefits
too.

[Dennis]

How are those descriptions not rules? Seriously, what is the pattern?

> >> - Show quoted text -- Hide quoted text -

[Dennis]

... I should add that I'm drawing a distinction between CQRS as a
principle vs CQRS as an architecture.

On Nov 18, 7:03 am, Nuno Lopes <nbplo...@gmail.com> wrote:

> >> - Show quoted text -- Hide quoted text -

[Nuno Lopes]

Hi,

> How are those descriptions not rules? Seriously, what is the pattern?

Seriously do you read. I wrote in the first sentence:

>> If there was a CQRS principle it would be something like this:

I was not stating that what CQRS is, I'm trying to give an example of what CQRS would be if it was Software Design Principle.

Patterns also follow design principles. Yet a Principle is not a result of a composition of Principles, in other words its not decomposable. Having model for query and a model for commands is not a fundamental law of software design, as such its not a Principle.

You may be wandering, what about SOLID? Well, SOLID its not a Principle either, its a Doctrine. A set of principles to be followed in software design. CQRS is not such thing either.

Each teams chooses the design principles over which his domain model will be designed. That makes the teams doctrine, it can be SOLID or something else-

Yet CQRS is more of the kind: "reusable software solution for a recurrent problem". First you need to identify the problem then look for the solution. CQRS can be it or not.

IMHO the kind of position you adopt towards CQRS, is IMHO the source of many problems.

Precisely because people think that its a Design Principle they stop looking at problem(s) for which CQRS was designed to deal with. Hence people apply it thinking that by following the rules described in the CQRS Pattern they will end up with a better design ... and the result is catastrophic! Why? Because the problems addressed by CQRS weren't there in the first place!

Now a Design Principle is not really such a case, if you don't follow the principles even though ones design may end up being bad, most probably you would get a far worst design if you did not followed them.

Cheers,

Nuno

[Dennis]

> I was not stating that what CQRS is, I'm trying to give an example of what CQRS would be if it was Software Design Principle.

I understand that... my point is, if its a pattern, describe it? How
is separating commands and queries a pattern? Furthermore, I directly
relate CQRS to the business domain. As a BDD(context specification)
practicioneer, I find it to be a natural way to interact with the
business domain expert. It helps frame the domain discussion around
behavior(commands) and the outputs(queries producing views). This is
not a pattern.

>
> Having model for query and a model for commands is not a fundamental law of software design, as such its not a Principle.
>

True is NOT a fundamental law of software design, however, it MOST
certainly is a fundamental law for CQRS. If you do NOT separate
commands and queries have you applied CQRS? Again, how is separating
read from write operations a pattern?

> You may be wandering, what about SOLID? Well, SOLID its not a Principle either, its a Doctrine. A set of principles to be followed in software design. CQRS is not such thing either.

Each letter in SOLID is a principle. I was drawing a comparison to
CQRS as a single principle say... SRP. That said, SRP is also a root
principle of CQRS.

> Precisely because people think that its a Design Principle they stop looking at problem(s) for which CQRS was designed to deal with. Hence people apply it thinking that by following the rules described in the CQRS Pattern they will end up with a better design ... and the result is catastrophic! Why? Because the problems addressed by CQRS weren't there in the first place!

I agree with the later part. However, teams can inappropriately apply
either a principle or pattern. Thats a discipline issue... or perhaps
even a business constraint.

[Nuno Lopes]

Hi,

True is NOT a fundamental law of software design, however, it MOST
certainly is a fundamental law for CQRS. 

So say Command Patterm is also a Principle because having separating responsibilities between an Invoker, a Command a Receiver and a Client is a fundamental law of the Command Pattern.

Yet you state that Command Pattern its a Pattern and CQRS is a principle.

This does not work

True is NOT a fundamental law of software design, however, it MOST

certainly is a fundamental law for CQRS.

Yes the Command Pattern also has fundamental laws so its a Principle right? 

That has been your point all along. Patterns have rules too (like a recipe), but that does not make it a Principle neither a doctrine so why isn't a Pattern a good qualifier for CQRS?

 As a BDD(context specification)
practicioneer, I find it to be a natural way to interact with the
business domain expert. It helps frame the domain discussion around
behavior(commands) and the outputs(queries producing views). This is
not a pattern.

I think it is better for you to you provide an example of this. Through it your point might cross much better.

I feel that your are making CQRS much more then actually is. A very simple Pattern.

Cheers,

Nuno

[Dennis]

> So say Command Patterm is also a Principle because having separating responsibilities between an Invoker, a Command a Receiver and a Client is a fundamental law of the Command Pattern.
>
> Yet you state that Command Pattern its a Pattern and CQRS is a principle.
>
> This does not work

This assumes a CQRS pattern can tell me how to separate the commands/
queries in any business domain... digital pathology, glass bottling,
etc. A software pattern cant prescribe a way to do that. It requires
business domain experts and CQRS mindset to frame the discussions of
how customers already want to talk about their domains... ie... the
commands(behavior) and its outputs(queries). That is the most elegant
part of CQRS mindset. Elegant because its crazy simple.

This statement also assumes this is an actual software pattern that is
uniquely "CQRS". In code, i would use resolve command messages to
command handlers... the command pattern. Thats not called the CQRS
pattern. Its the command pattern.

CQRS as a principle can be a business domain exercise. Not a coding
exercise.

> >  As a BDD(context specification)
> > practicioneer, I find it to be a natural way to interact with the
> > business domain expert. It helps frame the domain discussion around
> > behavior(commands) and the outputs(queries producing views). This is
> > not a pattern.
>
> I think it is better for you to you provide an example of this. Through it your point might cross much better.

Probably should create a separte discussion thread for that.

> I feel that your are making CQRS much more then actually is. A very simple Pattern.

Quite the contrary. The point of these 70+ threads is that is crazy
simple. The complexity can be incrementally added in as the result of
being disciplined around thinking about the business domain as
commands and queries. By complexity, I mean infrastructure to
implement EDA using a service bus with message queues etc.

In fact its so crazy simple... you dont need a framework. :)...
although you might use one for ES, service bus, etc.

[Nuno Lopes]

Why not this thread?

Honestly I don't understand. You say that simply separating a set of commands from the queries helps you driving BDD and communication with the stake holders and conclude as such is a Principle.

I'm asking for example to understand your stake. I gave examples to sustain mine, I think it is the least you could do to sustain yours.

Sent from my iPhone

[Dennis]

The reason I was going to start a new one is because this could easily
grow into something different.. but no matter. I've been as
forthcoming as possible up to this point. No? In either case, I
appreciate your participation.

So... a contrived business domain example ...using the digital
pathology field as an example... I might have a stakeholder story like
this:

[Epic - story is nothing more than a placeholder for a conversation]
In order to review a patient case outside the hospital
as a pathologist
I want to be able to view a scanned image of a slide over the internet

This story might drive a conversation to the following context
specifications (which incidentally is the acceptance criteria):

When opening a case
- It should display the case number
- It should display the list of associated scanned images

At this point of the discussion, I would interpret the stakeholders
description as a view which will result in generating a query object
(perhaps with a case id) and a query handler that can retrieve
(obviously ignoring the details about transport over HTTP.. maybe its
a web service from the client maybe its just a page request). In
either case, I have a query

When the slide (scanned image) has been viewed
- It should mark the slide as viewed

I would interpret this to be a command(behavior). I'd create a command
object and command handler. "IF" your applying DDD, I'd retrieve the
Case AR and execute the MarkSlideAsViewed(slideId). Perhaps your using
ES ... perhaps not. Obviously, this would be in a transaction etc etc.

Point of this is .... CQRS is first and foremost about the business
domain. Communicating with the customer to drive out commands and
queries. But they are none the wiser because I never forced them to
talk about command & queries rather i talked about their domain.

The benefit of CQRS thinking is I now have separated those
responsibilities and I easily begin scaling the system... as the
requirements and project progress dictates. I dont need to concern
myself with other architectural details until the last responsible
moment. The fact that I separated them at the onset, I can easily
address the complexities as the life of the project continues.

On Nov 18, 1:50 pm, Nuno Lopes <nbplo...@gmail.com> wrote:
> Why not this thread?
>
> Honestly I don't understand. You say that simply separating a set of commands from the queries helps you driving BDD and communication with the stake holders and conclude as such is a Principle.
>
> I'm asking for example to understand your stake. I gave examples to sustain mine, I think it is the least you could do to sustain yours.
>
> Sent from my iPhone
>

> > although you might use one for ES, service bus, etc.- Hide quoted text -

[Dennis]

... at this point no framework is needed. No CQRS pattern was applied.
I applied CQRS as principle to drive out the commands and queries with
my domain experts.

I would immediately create those specifications in code as
unimplemented spec... probably using a tool like MSpec. Incrementally,
I would begin building the command object and command handler; the
query object and query handler. Heck, I dont even need an actual data
store yet. I would drive out the use cases through working software
and deliver continuously placing working software in their hands.

Because of CQRS as a principle, I drive out commands and queries. When
and IF my project continues to grow... the other stuff will come in
due time. However, I could NOT easily take advantage of partionability
unless I first separated those things into separate objects.

At this point, I only need to use the command pattern. I only need a
simple dispatcher(invoker) that uses my container to match a command
object to a command handler and execute the handler. Much of the other
stuff is architectural.

At the domain model (persistent model) level, yes, I would absolutely
use ES. ES is super easy... even without a framework, although I'd be
incline to use Jonathon Olivers event store. My AR would only have
methods.

...

> > - Show quoted text -- Hide quoted text -

[Nuno Lopes]

Hi Dennis,

Thank for explaining the CQRS principle. Now it's crystal.

So you discovered Structured Programing and Structured Design with CQRS, that is a good thing.

Cheers,

Nuno

[Dennis]

Im pretty sure I didnt discover anything new. Just re-sharing the
fundamental points already made by the CQRS community (most notably
Greg and Udi, distributed podcast guys are also doing a great job...).

As new-comers want to learn about CQRS, emphasising CQRS as a
principle would deliver the essence quicker... IMHO of course. No
special patterns are required. Do you know the command pattern? Then
you already know how to get started coding. No framework is needed to
get started. As they grasp those concepts, CQRS as an architecture
"CAN" evolve to include the other orthogonal stuff. The other
orthogonal stuff has already been well defined and patterned... and
includes frameworks for those things.

[Tom Janssens]

I got tired of all this theoretical mumbo-jumbo, so I implemented what I consider a minimal CQRS app, in order to prove you can do both CQRS with and without a framework:

Architecture & all the blah in a single c# file: 

https://github.com/ToJans/MinimalisticCQRS/blob/master/MinimalisticCQRS/MiniCQRS.cs

UI in a single htm file (warning: ugliest layout in the world IMO - true developer art):

https://github.com/ToJans/MinimalisticCQRS/blob/master/MinimalisticCQRS/default.htm

Demo over at http://minimalisticcqrs.apphb.com/ 

The demo supports concurrent users afaik; so you can see the effect of other peoples changes in realtime....

Less talking, more code please....

[Nuno Lopes]

It is unfortunate that people learn programming without meeting the basic tenets of structured programming. Programming with procedures (your commands and queries) has been here form more then 30 decades, some are commands other are queries. CQS is usually applied here too!

I guess that Udi and Greg meet so many people in that poor situation that they feel the need to make a detour into those aspects of software design before actually diving into the relevance of having two models and why it solves some problems.

Building a facade of procs around our domain models is a quite common to.

I ask the community this.

If you feel that you don't need two models (I means models has a collection of data structures and algorithms), one for focused on providing services to query information and another for processing information, why would you need CQRS? I think most people don't know the answer to this question, hence are looking for a solution to a problem they never met and don't have.

On the other side, if you ever needed to deal with the impedance mismatch between supporting and using structures and algorithms for reading and for processing that CQRS might be for you.

I think this is crucial to understand CQRS.

Cheers,

Nuno
PS: An example of a structured programming language is C.

[Dennis]

Others believe this "theoretical mumbo jumbo" to be the fundamental
tenants of CQRS. Emphasis on a framework is NOT as important as some
would think.

I am not trying to prove "scritchy", NCQRS, Lokad.CQRS, Axon or any
other framework to be wrong. Specific categories of developers love to
FIRST jump to the code and frameworks. As a result, they miss the
essence and dont understand the "why". I'm emphasizing when/where and
what type of framework is needed when applying CQRS. Specifically, a
framework is NOT needed to get started. At the coding level, the
command pattern is all you need.

On Nov 19, 7:51 pm, Tom Janssens <d4sk...@gmail.com> wrote:
> I got tired of all this theoretical mumbo-jumbo, so I implemented what I
> consider a minimal CQRS app, in order to prove you can do both CQRS with
> and without a framework:
>

> Architecture & all the blah in a single c# file:https://github.com/ToJans/MinimalisticCQRS/blob/master/MinimalisticCQ...

>
> UI in a single htm file (warning: ugliest layout in the world IMO - true
> developer art):
>

> https://github.com/ToJans/MinimalisticCQRS/blob/master/MinimalisticCQ...
>
> Demo over athttp://minimalisticcqrs.apphb.com/

[Dennis]

> On the other side, if you ever needed to deal with the impedance mismatch between supporting and using structures and algorithms for reading and for processing that CQRS might be for you.
> I think this is crucial to understand CQRS.

+1

For me, I also believe CQRS (as a princple) is valuable in situations
where impedance mistmatch is NOT a concern. Because no special
framework or coding practice is required to get started, teams can
deliver working software quicker. However, "IF" the project begins to
grow, the separation of commands/queries will provide a strong
foundation to address things like impedance mismatch.

[Dennis]

> If you feel that you don't need two models (I means models has a collection of data structures and algorithms), one for focused on providing services to query information and another for processing information, why would you need CQRS? I think most people don't know the answer to this question, hence are looking for a solution to a problem they never met and don't have.

This why I believe CQRS is a principle. Teaching CQRS as a principle
will help people address those problems when/if they encounter them.
In the meantime, the reap the benefits of SRP and simple, supple
design that is NOT burdened by learning a framework. Of course, I am
assuming most teams already know the command pattern or could at least
learn it in 5 minutes.

As a basketball coach, young players often express their displeasure
for performing drills. Its not until we run the offense in a game
situation that they realize those drills help them execute the
offensive play. I think this basic idea exists with CQRS.

[Nuno Lopes]

Hi,

For me, I also believe CQRS (as a princple) is valuable in situations
where impedance mistmatch is NOT a concern.

I never seen either Udi or Greg explaining it as a Principle so I can only conclude there isn't yet such thing.

In fact CQRS as Principle leads to all sorts of problems.  For instance, the example you gave, I see no reason to use too models as prescribed by CQRS. One for queries and one for commands. 

All the examples I've seen Udi and Greg give where CQRS is applied suffer from the same simples. Let me try to explain with example

1) Greg's Event Sourcing

An event stream is a collection of atomic facts that result from applying any mutator to an Entity in order of application. Each fact exhibit a well defined structure. 

1.1) For real time queries this kind of model is not good enough even tough is most normalized structure one can have.  

1.2) For presentation is not that good either since the body of an Entity is somewhat lost.

So CQRS comes to the rescue, helping to create a separate model form reads.

2) Domain Models

The domain models is an excellent pattern to capture the UL. Yet, its structure rises several problems for queries. Query by object navigation is simple not as performant as query by data sets. Polymorphism and Interfaces also rises several difficult problems to solve. 

So you could build a separate model just for queries. Say a relational database model, a star model or whatever.

This avoids the use of Patterns like the Table Module that aren't that easy to map to the UL. 

CQRS can help.

3) First Law of Distributed Object Design: Don't Distribute your Objects.

I will not dive into the this law. Yes we should not distribute our objects, yet if we realize that a lot of contexts we do far more queries then transactions why not separate our query model from our domain model? Queries don't change data, so we could scale out our query model as much as needed, leaving our domain model alone in a machine or cluster dedicated in performing transactions.

CQRS can help.

4) Presentation

Domain Models, Relational Models, Event Models and so on, aren't really tailored for presentation to the user, neither for for user interaction. A common pattern used to solve this problem is MVC.

MVC is a particular case of applying CQRS.

5) Property Pattern & Adaptative Object Models.

Adaptative Object Model are quite common is ERP's, and Enterprise Workflow Solutions. In the later we can define entities, and workflows around entities, had actions from a pallet or integrate our own.

The problem of this models is they aren't really performant for queries. So why not build a separate table like model supporting queries?

CQRS can help.

6) The list goes on and on.

This is a pattern that deals with a technical problem. Much like the Command Pattern. There are patterns such as the Bounded Contexts, Core Model, Event Sourcing, Part-Role, Aggregate, Moment-Intervals-Transaction, and so on, that deal with translating domains (The UL) into a computer friendly model. If your are interested in them take a dive into DDD.

There are some Principles too in that realm. Such as, one each aggregate method should deal with just one use case, and one use case should be dealt by just one method. This forces you to makes things explicit. The same goes with Aggregates.

For instance in an Purchase Order BC operations such as adding and removing orderlines, or adding addresses etc, are really core? Or are operations such as Submit Purchase Order, Cancel Purchase Order and so on actually core. (The business makes money with submitted orders). Is adding an orderline a use case?

This is my last post. Hope it helps.

Nuno

[Nuno Lopes]

Hi,

Gosh my previous post was with so many written english errors that it may be hard to read. I apologize, english is not may natural language and that starts showing when you've been work for 15 days in a role.

Let me try to correct it to reduce the noise coming from this challenge of mine.

Hi,

For me, I also believe CQRS (as a princple) is valuable in situations
where impedance mistmatch is NOT a concern.

I never seen either Udi or Greg explaining it as a Principle so I can only conclude there isn't yet such thing.

In fact CQRS as Principle leads to all sorts of problems.  For instance, the example you gave, I see no reason to use too models as prescribed by CQRS. 

All the problems I've seen from Udi and Greg where CQRS is applied so solve it, suffer from the same symptoms. Let me try to explain with example

1) Greg's Event Sourcing

An event stream is a collection of atomic facts that result from applying any mutator to an Entity in order of application. Each fact exhibit a well defined structure. 

1.1) For real time queries this kind of models is not good in many situations.

1.2) For presentation is not that good either since the body of an Entity is somewhat lost in the midst of these highly granular set of facts.

So CQRS comes to the rescue, helping to create a separate model form reads.

2) Domain Models

The domain models is an excellent pattern to capture the UL. Yet, its structure rises several problems for queries. Query by object navigation is simply not as performant as query by data sets. Polymorphism and Interfaces also rises several difficult problems to solve in the context of queries.

So you could build a separate model just for queries. Say a relational database model, a star model or whatever.

This avoids the use of Patterns like the Table Module that aren't that easy to map to the UL. 

CQRS can help.

3) First Law of Distributed Object Design: Don't Distribute your Objects.

I will not dive into the this law. Yes we should not distribute our objects, yet if we realize that a lot of contexts we do far more queries then transactions why not separate our query model from our domain model? Queries don't change data, so we could scale out our query model as much as needed, leaving our domain model alone in a machine or cluster dedicated in performing transactions.

CQRS can help. If you use CQRS with Event Sourcing you can effectively remove the need for a ORM for this.

4) Presentation

Domain Models, Relational Models, Event Models and so on, aren't really tailored for visual interaction. A common pattern used to solve this problem is MVC.

MVC is a particular case of applying CQRS!

5) Property Pattern & Adaptative Object Models.

Adaptative Object Model are quite common is ERP's, and Enterprise Workflow Solutions. In the later we can define entities, and workflows around entities, add actions from a pallet or integrate our own.

The problem of these models is they aren't really performant for queries, since the set of properties of an Entity is dynamic. So why not build a separate table like model supporting queries?

CQRS can help.

6) The list goes on and on.

This is a pattern that deals with a algorithmic problems, no so much with translating the UL to a software design. Much like the Command Pattern. There are patterns such as the Bounded Contexts, Core Model, Event Sourcing, Part-Role, Aggregate, Moment-Intervals-Transaction, and so on, that deal with translating domains (The UL) into a computer friendly model. If your are interested in them take a dive into DDD.

In DDD you'll find Principles that help you translate the domain into a domain model. The benefits of a domain model is that it is easier to talk about it with stakeholders. 

One of the Principles is:  Each Aggregate Root method (An AR is an Entity) should deal with just one use case alone, and one use case should be dealt by just one AR method. This forces you to makes things explicit. The same goes with Aggregates. (The first person I saw presenting this was Udi)

For instance in an Purchase Order BC operations such as adding and removing orderlines, or adding addresses etc, are really use cases? Or are operations such as Submit Purchase Order, Cancel Purchase Order and so on actually relevant use cases. (The business makes money with submitted orders). So probably you can remove operations such as adding and removing other lines from the PurchaseOrder.

This is my last post. Hope it helps.

Nuno

PS: I've never went to a training session, neither from Udi, Greg or Eric. All I've learned about CQRS is from the info available on the net. including this forum. Of course the above observation are influenced by my 25 years in making software. To learn we just have to listen.

[Rinat Abdullin]

1. I believe the more fitting term for the overloaded "CQRS Architecture" is "Event centric architecture". CQRS in itself is just a principle nothing more.

2. As for the frameworks, I absolutely agree that they are not needed to get started with the technology (or even to deliver projects).

More than that, some of the frameworks can even be harmful for the projects by enforcing their own constraints and assumptions (i.e. how NServiceBus by default enforces coupling with it's libraries and embraces transactional behaviors out-of-the-box).

They only reason for which I still use my own Lokad.CQRS framework is message delivery & dispatch mechanism for cloud-ignorant deployments (and actual TPL runner engine). Everything else is overcomplicated junk there :)

Best,

Rinat

[stacy]

"Everything else is overcomplicated junk there :)"

I certainly admire you Rinat for going so deep down that cloud rabbit hole. Doing so has served the community well, IMHO - flushing out what works in the real-world, and what doesn't, with this nascent CQRS principle.

[Greg Young]

SOLID is a set of heuristic rules. The rules are all breakable in many
circumstances.... They are rules at a given level of understanding at
higher levels they do not matter. The solid rules (minus liskov) are
heuristics over Ca/Ce and cohesion.

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Nuno Lopes]

> They are rules at a given level of understanding at
> higher levels they do not matter.

True. You are correct that at enough higher level all that matters are commands and queries. This is just not a perk of CQRS. But at that level there is really little one can do if there is a design flaw in the system without major $$$.

Cheers,

Nuno

[Rinat Abdullin]

Nuno,

We've been doing improvements in our systems (with horrible initial flaws) with limited amount of time and effort. So it definitely is possible and repeatable.

Best,

Rinat

[Nuno Lopes]

HI there Rinat,

I've not been following your developments as I would like. Having said this it seams that most the concerns addressed in your blog are around Aggregates, Event Sourcing, Bounded Contexts and other DDD Patterns, and how you applied CQRS on top of those.

These Patterns are for me orthogonal to the CQRS Pattern and with each other (yes, I can use Bounded Context without CQRS or even Aggregates). In ones design we can get them together of course.

From this I believe that you have far more DDD stuff in your bag then CQRS that empowers your remark.

Greg's experience in Financing and EDA opened my eyes not with CQRS, but a very simple thing. Command -> Aggregate -> Event/Fact ... this for me is really powerful, way beyond CQRS. You seam to use this heavily.

Cheers,

Nuno
PS: Maybe its me, but when people start taking about Maturity Models, Meta Models etc, around a Pattern as simple as this I get the shivers. Maybe we should talk about MVC, Specification, Command Pattern, CQRS, Table Module, Presentation Model, Domain Model .... Maturity Models, Meta Model and so on.