> You would need to redefine what CQS is in order for this statement to be true.If you recall our discussions with Martin (Fowler), he was against
naming a new pattern. My position on CQRS included the data separation
which, in my mind, made it different not just in degree but also in
kind from CQS. I thought (at the time) that you were in agreement.
> If I am using the same data source, that means that I have chosen toIt is not a question of "mode of integration" (and I'm pretty sure you
> separate my interfaces but have decided for these interfaces that I
> wish to integrate through the database in your version you integrate
> through events. Why would changing the mode of integration of the two
> interfaces make it a completely different pattern? Would it be yet
> another pattern if I chose to integrate through non-event based batch
> operations (not that I would recommend this).
know that). The eventual consistency arising from separate data
sources leads to a very different architectural and business context.
If one were to use say an ETL job for keeping those data sources in
sync, I would view that as a different implementation of the same
pattern (but a pretty poor and undesirable implementation all things
It is also this eventual consistency that is reflected by one-way
I can understand your position of looking at all of the various pieces
> The real value of a pattern is that we can communicate complex concepts with very few words...Agreed, but I'd say that a code-only definition of CQRS overlaps too
> when we use the same pattern name to describe many things it causes confusion amongst people
much with CQS potentially causing confusion that way. That was
Martin's position as well.
You could also say that the code-only definition is similarly an
extension of the single responsibility principle and the interface
By applying the "prefer building block" state of mind you were
describing, we should be talking CQS, SRP, ISP rather than code-only
On the DDD bounded contexts (SOA/EDA breakdown), while you might say
> Per collaborative domains, I can come up with non-collaborativeI agree that the various building blocks can be used in all sorts of
> domains that would still benefit from applying said architectural
> ideas (especially event sourcing or storing a historical event log)
> although in general I think you will find collaborative domains are a
> better match. I don't believe however that there is any direct
> causation between collaboration and the use of these patterns.
combinations in many kinds of domains (including non-collaborative
ones). That being said, it is useful to have prescriptive guidance to
point people who may not understand all the nuances in (more or less)
the right direction. What I can say from a causation perspective is
the collaboration does mean system/user level eventual consistency, so
it is a pretty good heuristic for using CQRS as I describe it.
-- Udi Dahan
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.