The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
From: Udi Dahan <thesoftwaresimpl...@gmail.com>
Date: Mon, 2 May 2011 22:19:39 -0700 (PDT)
Local: Tues, May 3 2011 1:19 am
Subject: Re: How to avoid CQRS
Greg,
> 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 to
It 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 considered). 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 segregation principle. By applying the "prefer building block" state of mind you were describing, we should be talking CQS, SRP, ISP rather than code-only CQRS. On the DDD bounded contexts (SOA/EDA breakdown), while you might say
> Per collaborative domains, I can come up with non-collaborative
I 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. Cheers,
-- 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.
| |||||||||||||