Apparently we are in a cult..
Adam Dymitruk
This is the way a normal person should see CQRS according to Jak:
"CQRS - The Cult of Shiny Things
CQRS has become another casualty of the buzzword culture and the cult
of 'shiny things'
What started as a collection of some reasonably good principles has
now turned into an almost religious mantra for some, with more and
more outrageous claims, and almost no basis in fact or experience.
Scalability
Claims like "almost infinitely scalable systems" associated to CQRS
are ludicrous, especially as none of the currently "near infinitely
scalable systems" use CQRS or have probably even heard of it. The
largest systems on the planet have no need of CQRS, they use many
tricks and techniques that have been associated with CQRS - but they
don't use it, nor are they ever likely to use it, because when you
have really large systems, things like CQRS become totally irrelevant.
The scaling benefits of CQRS come from understanding eventual
consistency and messaging - concepts that were around long before
CQRS, and that will be around long after it too.
Task Based UIs
Well, yes CQRS may require a task based UI, but task based UIs were
again around long before CQRS, and will again outlast it. This is just
a different way of thinking about how people interact with computers -
this is a UX issue, not a technical one.
In fact, if anything, CQRS can be a major cause of issues here - when
you really have a CRUD style system, CQRS is going to cause you all
sorts of issues you will need to resolve. And much as I dislike CRUD
based UIs, the reality is we have abused users to work this way in
many cases - so sometimes that is just how we have to make our next UI
work.
Side Effect Free
Another aspect of CQS (and by extrapolation CQRS) is that functions
employing CQS are side effect free - you don't accidentally introduce
subtle bugs by writing and reading in one operation.
And while this is nice in theory, the scale of system where this
preventative measure would have benefit is the one where this problem
is just as easily solved by many other simpler means, like just
writing smart code. Larger systems have so many points in them where
read and write are already being mixed, CQRS here just lends an
illusion of safety.
Denormalised Read Models
A valuable benefit of CQRS is the concept that the views have specific
read models that are denormalised from the (presumably) complex domain
model.
This has a number of benefits, though these are largely boiled down to
improved efficiency of querying (and action that tends to happen
frequently). These models can also be extrapolated out to provide
reporting and MI models too.
But again, we have been doing this for many years already, and usually
to account for overloaded database servers that we don't wish to query
against, particularly with MI.
And querying these days, even with horribly complex joins on highly
complex models is becoming faster and faster. Push querying to a slave
server, and you gain all the benefits of a rich model, and fast
queries. And for even more speed you can look to NoSQL solutions -
which are effectively based on the principle that you denormalised
your data anyway.
Performance Considerations
Part of the theoretical benefit of CQRS is that your queries will be
faster as your denormalised datastores are updated at write time, so
you don't have to do horrible joins on queries (which in theory on
most systems happen far more frequently than writes)
These days, the performance of relational databases and especially
NoSQL databases is advancing rapidly. The new breed of databases takes
things like sharding and replication very seriously, and as first
class features, not afterthoughts like the databases of old did.
Replication in MySQL takes roughly 0.0002 of a second (see
http://nr-content.s3.amazonaws.com/railslab/videos/17-ScalingRails-Scaling-Your-Database-Part-1.mp4
at 6 minutes in) - compare that with how long a message based approach
like CQRS will take to push that to your secondary datastores and you
are talking orders of magnitude faster for the dumb replication
approach. Apparently it operates at this speed for up to 10 slave
databases before degrading.
Now, think about this bit, the 37 Signal systems (a huge system)
operates on a single MySQL instance running with 105Gb of memory
caching. And 37 Signal could be considered the archetype of an Active
Record approach, after all it is the reason Ruby on Rails exists. Are
you writing a system that big?
Maybe you are so let's examine a larger system - Wordnik stores over
12 billion documents, 3Tb of data per node, 500k requests per hour and
4 times that at peak load, and yet their fetch time is around 60ms.
(http://blog.wordnik.com/12-months-with-mongodb)
Let's not even begin to discuss Twitter, Ebay, Facebook or other
similar "mega systems" - they still respond in milliseconds with tens
or hundreds of millions of users - think that's down to CQRS?
Dealing with Complexity
Yep - CQRS deals with complexity to one degree - it forces you to
explicitly think about what each call is doing - "Is this writing data
or reading data?" - and that thought process is a good thing.
But it introduces another layer of complexity that is more subtle and
harder to deal with - the replication to secondary datastores is
complex in itself - it effectively needs to do that horrible join you
are trying to avoid in your queries so that it can update your
denormalised tables. That in itself isn't simple.
But it also needs to be able to maintain those secondary datastores
if, for example they are corrupted and need recreating or if they miss
some messages. In normal replication this is trivial, drop the slave,
add a new slave - wait a short while - someone already wrote all that
for you on a database system - you are going to need to write it all
yourself with CQRS.
So Why Have I Implemented CQRS Before?
Well, at the time I first implemented CQRS I had two reasons for doing
so - and oddly neither had to do with any of the aforementioned
technical aspects. In fact, one was a technical problem and one was a
people problem.
Firstly this was nearly two years back, and the system that we were
writing a layer over was a very old and crumbling legacy database
system. It had no real normalised schema, and was open to abuse from
just about every development team in the organisation without warning
to others - it was also horribly prone to outages.
One project had just "failed" (though I'm sure some would say it was
just a lesser success), primarily due to trying to put a domain model
on top of the legacy database.
So, the problem we had was to create a disconnected system that could
operate independently of the legacy system, but also use the legacy
system as it's true authority for the information it used. Because of
the horrible complexity in the legacy system, using CQRS allowed us to
write what were frankly quite horrible SQL statements for reading data
from legacy, while using a pseudo-document database for the daily
operations. We then used horrible SQL statements to replicate this
data back into legacy.
Of course, what we were really writing was a standard message based
architecture, but the term CQRS encompassed that quite nicely.
We could have approached this without the CQRS badge - but it served
as a useful political tool - a number of the existing team had heard
of it and were quite enthusiastic, and management would be confounded
enough by it to not get in the way too much. It also broke the mental
model the development teams had with "put an ORM over the database".
So the secondary benefit of CQRS here was a people problem - it was a
new buzzword - it got new enthusiasm from a team that was demotivated
from the previous project - and more than anything - that motivation
was going to be the key to the success or failure of the new project.
So Why Have I Presented On It Before?
Well two reasons really, the first being that I have always tried to
dispel the mythology around CQRS and to explain the real benefits of a
flexible and scalable architecture - it just so happens that people
want the buzzword explaining - you have to admit it's a pretty vague
and fuzzy term with a myriad of definitions and explanations.
The secondary reason being, as my last presentation at DDD Sydney
explained - my objective was to make you think. There's a lot of good
things hiding under the CQRS banner, and I really would like people to
think about better ways of writing software.
Conclusion
In the few years since CQRS was "invented" it has got a bit of a cult
buzzword status. It is talked about as though it fixes a multitude of
problems.
But in that time, NoSQL has really taken off. RBDMS' have got far more
powerful. And memory and processing power has increased significantly.
Database caching is exceptionally impressive. REST gives us proxy
caching for near enough free. Memcached and Velocity make light of
massive data loads. We even have the nefarious "cloud" now, where
processing power and memory is cheaper than the effort involved in
maintain complex architectures.
Scaling systems is now a pretty commonplace business problem for most
of the startups taking off -and they don't need CQRS - there is a
very good chance you don't either. We are past that point in time
where we had to prematurely optimise things like database queries.
If it's about thinking differently, then I can tell you all you need
to know about CQRS in a simple paragraph:
Learn to think of systems as being inconsistent at all times, no
matter what illusion they present of 'real time'. Learn to embrace
messaging, REST, caching, replication, sharding, and a hundred other
techniques to solve these problems. Embrace user centric task based
UIs, embrace strong UX, embrace strong domain driven design, embrace
business led functionality and delivering systems that match real
requirements. Embrace thinking differently.
CQRS is no silver bullet, in fact it has almost now become a solution
to a problem that doesn't exist any more. If you can give me a problem
that CQRS claims to solve, I'm fairly sure I can solve it more easily
than I could have done 2 years ago when I started using CQRS. I'm sure
I'll still use a lot of the things that CQRS encapsulates, because
they are after all very good principles - I'm just pretty much over
playing buzzword bingo!"
is what Jak said.
--
Adam
http://adventuresinagile.blogspot.com/
http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvan.grou.ps/
João Bragança
Adam Dymitruk
Michael Brown
give a formal name/methodology to practices that have been accepted in the
industry for years. MISSION ACCOMPLISHED.
Rinat Abdullin
On Wednesday, November 3, 2010, Michael Brown
--
Best regards,
*Rinat Abdullin*
Technology Leader at Lokad.com <http://www.lokad.com> | Writer at
Abdullin.com <http://abdullin.com> | Contacts <http://abdullin.com/contact/>
Nuno Lopes
> So what he's saying is that DDD and CQRS/Event Sourcing do little more than
> give a formal name/methodology to practices that have been accepted in the
> industry for years. MISSION ACCOMPLISHED.
No, is stating stuff about CQRS/ES. DDD he ack has something extremely practical.
>> formal name/methodology to practices that have been accepted in the
>> industry for years. MISSION ACCOMPLISHED.
No. He his stating that is CQRS neither is sufficient or a precondition of "infinite scalability". He is arguing for that matter other things beside CQRS are needed.
>> Side Effect Free
>> Another aspect of CQS (and by extrapolation CQRS) is that functions
>> employing CQS are side effect free - you don't accidentally introduce subtle
>> bugs by writing and reading in one operation.
Actually he writes about this is even more confused about it because he still thinks that a CQRS is a side effect free approach. But his confusion is not from someone that came from mars since once upon a time CQRS was called CQS and compared with the CQS principle.
The reality is that CQRS is anything but side effect free. Simply put, eventually consistent systems by definition ARE not side effect free. De-normalization is not a side effect free activity either.
That is WHY ES is important for CQRS in some cases. In order to cope with side effects in a systematic manner we need history!
It said that CQRS requires a Task based UI. True, but so do most enterprise architectures based on RPC.
Generically speaking what is saying is that he still does not understand specifically what kind of problems CQRS provides a solution to. Even though he as been using it. He only found out that it wasn't a solution for his problem when indeed he found the solution for his problem.
Now do you know if CQRS solves the problem you have? If you do maybe you can help him out.
Cheers,
Nuno
Neil Robbins
With all due respect I may disagree with Jak but to be honest people start behaving like a cult when they loose rationality.
No, is stating stuff about CQRS/ES. DDD he ack has something extremely practical.
> So what he's saying is that DDD and CQRS/Event Sourcing do little more than
> give a formal name/methodology to practices that have been accepted in the
> industry for years. MISSION ACCOMPLISHED.
No. He his stating that is CQRS neither is sufficient or a precondition of "infinite scalability". He is arguing for that matter other things beside CQRS are needed.
>> formal name/methodology to practices that have been accepted in the
>> industry for years. MISSION ACCOMPLISHED.
Actually he writes about this is even more confused about it because he still thinks that a CQRS is a side effect free approach. But his confusion is not from someone that came from mars since once upon a time CQRS was called CQS and compared with the CQS principle.
>> Side Effect Free
>> Another aspect of CQS (and by extrapolation CQRS) is that functions
>> employing CQS are side effect free - you don't accidentally introduce subtle
>> bugs by writing and reading in one operation.
The reality is that CQRS is anything but side effect free. Simply put, eventually consistent systems by definition ARE not side effect free. De-normalization is not a side effect free activity either.
Nuno Lopes
> The read side of CQRS is side effect free though isn't it - at least in terms of Meyer's definition which limits it to Observable side effects.
IMHO that is an artifice of reasoning, another rhetoric point of no value. The context of Mayer's CQS is not about evaluating side effects of reads only or writes only, but articulating reads with writes in conjunction over facts on the same set. His articulate goes on the premiss order of execution is preserved by the underlying computing system.
The principle is so that when we execute two reads over the same set of facts, we still get the same set of facts provided that no command was executed in between.
CQRS does guarantee that at all. By separating the model for reads and model for writes you can very well execute a command over a set of facts, then another command, read over a set of facts on the Views, and then read again only to find out that facts have changed even though both reads where executed after the commands.
The fact is when we execute a command not only state changes but also an event is published! An event that needs to be processed by the read side in the ORDER they where executed otherwise not only you get eventually consistent view but also bananas with it. Now events can arrive out of ORDER in CQRS.
The fact that issue of ORDER events matter is the proof the CQRS is not side effect free for the scenarios usually considered of great value.
Temporal side effects are non existent if the order is maintained. Otherwise there are side effects that need to dealt with code. Some event with business process reengineering.
Hope it helps,
Nuno
Nuno Lopes
Nuno Lopes
Just clarifying a point that some of may take on board as a benefit, when it is not the case.
Nuno
Neil Robbins
Disagree. Meyers driving idea behind CQS is to simplify the work for a developer of a client by establishing a convention around how members of an interface will behave based on the signature of any member. The critical guarantee made by any query member is that by the client calling it there will ne no discernable impact on the observable state which a call to this member (or any other member belonging to that type) renders.
Exactly this guarantee is made (or should be) in a CQRS system. It goes directly to the core of the separation, otherwise queries and commands are no longer distinct (so no meaningful responsibility segregation)!
That the impact of the command side may have an effect on the query side which causes changes over an indeterminate period of time is immaterial to a discussion as to the presence or absence of CQS in CQRS (which frankly seems absurd & contrived) since the command side is clearly solely responsible for any changes to observable state.
Neil Robbins
Also, with CQRS:
Events need never be published;
Eventual consistency is not necessary;
Events, if published, may arrive out of order in CQRS, *may*, but this is still a logical part of command processing & there are trivial PoEAI which will ensure the application of updates to query sources in an appropriate order (not that the absence of this is significant when considering whether CQRS extends, but maintains, CQS)
If doing ES then typically the event being published is the only cause of a change in observable state, a change in the internal state of an aggregate is practically immaterial from a CQS POV.
Temporal side effects as you call them are still side effects originating from the processing of a command, so the effect of calling a query is still side-effect free.
On Nov 3, 2010 7:08 PM, "Nuno Lopes" <nbpl...@gmail.com> wrote:> The read side of CQRS is side effect free though isn't it - at least in terms of Meyer's definiti...
Nuno Lopes
Meyers driving idea behind CQS is to simplify the work for a developer of a client by establishing a convention around how members of an interface will behave based on the signature of any member. The critical guarantee made by any query member is that by the client calling it there will ne no discernable impact on the observable state which a call to this member (or any other member belonging to that type) renders.
Eventual consistency is not necessary;
Simon Harris
Eventual consistency is not necessary;True, yet applying CQRS explicitly on a solution where with no plans to use eventual consistency for scalability purposes is an exercise of waste (IMHO).
Nuno Lopes
> Hmmm i must beg to differ. I don't need eventual consistency but if i consider events as the protocol, it provides me with great opportunity to separate the construction of the UI from that of the core domain model.
True. But for that purpose you can also consider implementation around MVC and Presentation Model. In particular MVC the does not mandate the use of event to populate views yet a lot of solutions make use if them for this purpose (Real Time View updates).
Myself I find hard to make a distinction between CQRS and MVC if not in context. So I'm guilty of some ambiguity in my position regarding CQRS and eventual consistency. Although CQRS does not requite eventual consistent, most interesting technical discussions around CQRS to me are under this premiss.
Still to me MVC is CQRS. So such generic term I agree with you.
Cheers,
Nuno
Neil Robbins
- querying can be more efficient (both the creation of queries & their execution)
- domain entities need not expose query methods (keeping their responsibilities cleaner)
- database access requirements can generally become far simpler, obviating arguments for ORM like techs (which introduce their own issues for ownership & dev)
Simon Harris
>> Hmmm i must beg to differ. I don't need eventual consistency but if i consider events as the protocol, it provides me with great opportunity to separate the construction of the UI from that of the core domain model.
>
>
> True. But for that purpose you can also consider implementation around MVC and Presentation Model.
Indeed I can use one of many approaches however none are trivial, all have with pros and cons thus I cannot see a basis for concluding that one in particular is a waste. For me, the conceptual simplicity of the architecture (ignoring eventual consistency concerns) was and still is highly attractive. I'm finding it much more closely aligns with my mental model than other solutions i have attempted in the past.
Simon Harris
Neil Robbins
Neil Robbins
Mark Nijhof
--
Mark Nijhof
m: 0047 95 00 99 37
e: mark....@cre8ivethought.com
b: cre8ivethought.com/blog/index
"Walking on water and developing software from a specification are
easy if both are frozen."
-- Edward V Berard
Simon Harris
--
Greg Young
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention
Nuno Lopes
> For me, the conceptual simplicity of the architecture (ignoring eventual consistency concerns) was and still is highly attractive. I'm finding it much more closely aligns with my mental model than other solutions i have attempted in the past.
Don't understand why CQRS is so simple and MVC so complicated.
http://codefish21056.blogspot.com/2010/08/cqrs-mvc.html
Cheers,
Nuno
Nuno Lopes
OOSC is one of the books that I recommend to everyone. It is imho the best book to learn the underlyings of OO.
Tom Janssens
While a lot of things posted on this newsgroup look spectacular, I am
using some kind of "dumbed down" version of CQRS with a lot of
success.
These are the advantages IMHO:
Consistent layering:
I currently use commands, events and queries to separate my app in 3
layers
- Front-end: an MVC infrastructure where the controller either queries
viewmodels or sends commands to the bus and redirects to another
controller method based on the validation of the command.
- Domain layer: interprets commands and delegates them to AR's, which
publish domain events; commands can be executed in a background thread
if they implement the IShouldExecuteAsync interface { bool IsAsync
{get; }}
- Viewmodel layer: updates viewmodels based on the domain events
Storage is as simple as a single table { Guid,Blob } + some specific
tables for viewmodels which can be queried (i.e. search for xxx)
My repository for most of the domain state/viewmodel state contains
only two methods: Fetch<TState>(Guid id) and Modify<TState>(Guid id,
Action<TState> modification)
By using CQRS I got rid of an ORM and AutoMapper => lots of
overhead...
I could separate the views from the domain easily but I don't need it
ATM.
Integration testing is a breeze now:
- send some events to the bus
- send a command
- check whether some events occurred
BDD does not really require gherkin language any more since commands
and events are understandable by the domain experts.
Currently event sourcing is not used here, but I am considering it,
since it would make refactoring/altering the domain state
effortless...
Nuno Lopes
Eventual consistency is something that is particularly painful to accept within a system.
One of the key benefits that CQRS brings is in simplicity to the codebase & design. By separating the query side from the write (even over a consistent store):
- querying can be more efficient (both the creation of queries & their execution)
- domain entities need not expose query methods (keeping their responsibilities cleaner)
- database access requirements can generally become far simpler, obviating arguments for ORM like techs (which introduce their own issues for ownership & dev)
So I would argue that CQRS (as described by Greg on his blog) does not need eventual consistency between the query and command sides, and that introducing this unnecessarily is to introduce unnecessary costs both to development and ownership.
"From the Command-Query Separation principle follows a style of design that yields simple and readable software, and tremendously helps reliability, reusability and extendibility." (handily I keep the pdf copy of his work on my laptop & my kindle as it is one of the few texts which I find myself returning too again & again)I don't think that anyone would argue that eventual consistency leads to simple and readable software, nor help reliability (not the same thing as availability). It may help extendibility, but I think even that would be open to debate. Note I am not discussing EAI scenarios here (say updating the corporate CRM from a LOB system) where such qualities as referential transparency are less of a benefit. I am particularly considering the relationship between the query and command parts of a system.
Neil Robbins
Hi Neil, thank you for your reply,Eventual consistency is something that is particularly painful to accept within a system.
Not really. Usually it is usually quite acceptable between bounded contexts. At least In my experience.
One of the key benefits that CQRS brings is in simplicity to the codebase & design. By separating the query side from the write (even over a consistent store):
- querying can be more efficient (both the creation of queries & their execution)
- domain entities need not expose query methods (keeping their responsibilities cleaner)
- database access requirements can generally become far simpler, obviating arguments for ORM like techs (which introduce their own issues for ownership & dev)
I've been using ORM's for quite awhile. Like Evans my experience with OO is on par with Relational systems. Directly accessing the database to perform queries for UI purposes, bypassing the model is quite a norm around here.I strongly advise this practice as it is a Win Win situation. Yes you probably loose some independence to database tech, but nothing you can't tackle with repositories. Added to this, creating Views over a relational database is a snap.Try using an ORM for object persistence and the relational model for queries. You will find the same benefits you argue with no events.
Greg's ideas makes the case of a cohesive set of benefits in his approach. When you start pealing his approach of its one by one benefits because you just need part of it, other solution exist that speed up the development greatly IMHO.Greg's for instance makes a strict interpretation of AR. Point being that two of his ARs may be eventually consistent. (no UoW across ARs) This makes the system extremely flexible in terms data deployment, yet other have also argued that this interpretation its just one amongst other. Leading to conclude that a lot of people use UoW across ARs.Still, you can Greg's AR interpretation with an ORM.So I would argue that CQRS (as described by Greg on his blog) does not need eventual consistency between the query and command sides, and that introducing this unnecessarily is to introduce unnecessary costs both to development and ownership.True, true. But simpler approaches exist in such cases IMHO. Read the above.Across BCs we would need 2PC in order to keep things consistent but it is costly in high volume transaction systems. So we don't usually do this around here. So systems are eventually consistent.
Around here, though we don't use event's yet for system integration, mostly because of technical difficulties and culture. For instance integrating our backend services with Sales Force using events is hard since there isn't has of yet a common Bus. So we need to use standard SISS for batch uploads, computing differentials each time along with logs. ES would simplify that greatly, along with ES for auditing and correctness.So I see great benefit on CQRS in terms integration of BCs even if we don't use ARs as Greg does. The bottom line for me is indeed the need for eventually consistent BCs. In my experience, is that even if there are no scalability issues, we sometimes are forced by the technology.
"From the Command-Query Separation principle follows a style of design that yields simple and readable software, and tremendously helps reliability, reusability and extendibility." (handily I keep the pdf copy of his work on my laptop & my kindle as it is one of the few texts which I find myself returning too again & again)I don't think that anyone would argue that eventual consistency leads to simple and readable software, nor help reliability (not the same thing as availability). It may help extendibility, but I think even that would be open to debate. Note I am not discussing EAI scenarios here (say updating the corporate CRM from a LOB system) where such qualities as referential transparency are less of a benefit. I am particularly considering the relationship between the query and command parts of a system.That is basically my point. So CQS becomes a mute property in those circumstances. In the circuntances where we don't need eventual consistency I would advise other techniques which makes the CQS on CQRS a mute point once again.
Cheers,Nuno
Greg Young
Nuno Lopes
Try using an ORM for object persistence and the relational model for queries. You will find the same benefits you argue with no events.This is basically what I'm advocating and I would see this as a vanilla CQRS implementation. The only point of departure for me would be to consider not using an ORM on the command side - but whatever works for you or your team, I don't think it's a big deal in this context.
Neil Robbins
Nuno Lopes
> But the context here is not one between bounded contexts, but between the query and command parts of the same context. The trade off is very different.
> Again, I'm not referring to eventual consistency between systems (entirely different set of arguments apply here), but to the eventual consistency within a context (between its query and command parts).
Why do you assume that on top of a View is the UI and immediately the user? Couldn't there be another BC reading data from the view and making decisions over it? It may as a result send a command back to the BC but not necessarily.
Quite often the Application Layer were Views reside are used as integration points (composites).
Cheers,
Nuno
Neil Robbins
Nuno Lopes
Try using an ORM for object persistence and the relational model for queries. You will find the same benefits you argue with no events.
- NunoThis is basically what I'm advocating and I would see this as a vanilla CQRS implementation. - Neil
One technique (at least with SQL Server) is to persist the object as XML and use views over that to provide a consistent, but simple, source for queries. - Neil
Neil Robbins
Neil Robbins
Ian Cooper
> So what benefits might I see in CQRS without eventual consistency? One of
> the key benefits that CQRS brings is in simplicity to the codebase &
> design. By separating the query side from the write (even over a consistent
> store):
> execution)
> - domain entities need not expose query methods (keeping their
> responsibilities cleaner)
> - database access requirements can generally become far simpler,
> ownership & dev)
layered architecture that funnelled both read and write through the
domain, with unecessary complexity around building our viewmodel (both
from the need to issue multiple queries through touching many ARs and
code to map multiple DTOs that often carried far more data than we
needed into a single view model). Letting the presentation layer talk
to the Data layer and use a transaction script approach, freed us from
the tyranny of our domain. We also as a reinforcement slimmed down Fat
Controllers and Domain Services.
We didn't break from an ORM for this though the probelms caused by the
loss of information hiding from being forced to expose our entities'
state properties and the tendency of devs to use once it was exposed
would be a good reason for me to consider shifting to a reflection
based home rolled one. We wanted the caching support because we were
metadata heavy, but I can certainly see a model that could obviate the
need for a 2nd level cache by pre-claculating the outcome of metadata
from writes so that reads neer needed to figure it out, and making
sure that my SQL server buffer was large enough. That's food for
thought to resolve smells around ORMs that still trouble me
> So I would argue that CQRS (as described by Greg on his blog) does not need
> eventual consistency between the query and command sides, and that
> introducing this unnecessarily is to introduce unnecessary costs both to
> development and ownership.
the picture. My understanding from what I see Greg talk about is that
capturing the transactional nature of the domain is the driver behind
event sourcing not scaling (although that you can use it to scale is
of utility). That is why I would tend to pitch event sourcing as a
domain concept not as a infrastructure concept. Indeed we used it
within our domain to solve specific issues of a highly transactional
domain (insurance) and used it to solve complex transactional problems
(out-of-sequence mid-term adjustments) that plague many systems in
that space. IIRC the first time I remember Greg talking about event
sourcing he hedged it in terms of the failure of audit trails and
asking yourself the question, what is my audit trail requirement for,
how would it be used, and how could it be proved is the first step to
seeing where event sourcing comes in your domain. But yes, talk of
'how does Amazon' scale' is I think something of a red-herring.
Ian
Nuno Lopes
I'm not assuming this at all - the nature of the BC's client is surely immaterial? I'm not sure how what I've written could be interpreted as making that assumption but it wasn't intended.
Neil Robbins
Neil Robbins
Ian Cooper
On Nov 4, 4:57 pm, Neil Robbins <neilarobb...@gmail.com> wrote:
> What I might do though is to go as far (is it far?) as to suggest that
of this was narratives+patterns Fowler style.
As part of that I think that it would be worth outlining what you need
to compensate for in each combination of the various techniques i.e.
if you choose CQRS with Full Consistency what do you need to win/lose,
what are your compensation strategies for that. I think that would
help folks deal with constraints that they have, select an appropriate
response, and understand the cost of what they have chosen.
Nuno Lopes
> Most users I know do expect the screen to be consistent with the model. If I put a book in my shopping basket I'm sorely disappointed if it's no longer available when I get to the end of the purchasing process.
Humm. I think the users expect that what they see is consistent to with their inputs. No so much consistent with some back end system. They do understand, that it might be the case that when some input is provided it might still be rejected, even though it seams consistent with what they view, simply because conditions have changed. As long has this does not happen systematically is not considered a bug, but an effect of concurrent access, whose cost is less then sending a fax.
> If however I'm the underwriter (well assistant underwriter, lets keep this realistic) and I create a new policy in the system I expect that policy to be present when I go to view it & I expect, perhaps more importantly, that the quotes for that customer will not allow me to create a further policy for that customer from them. When I see that quote (even if I've had the 0.5 day training) I'm likely to try and create the quote again. (yes we can then jump through hoops however seemingly trivial to deal with that users problem).
The problem you describe is when the Policy is submitted and considered correct by the system and does not appear listed in the next screen (for instance), not so much when it is considered incorrect. Provided that the system is able to present the submitted policy in a workable time frame there is no problem. One way commands are not very in situation where the system is available. If not available, there is some value still in being able to submit the policy event though is not immediately processed. So adaptable system that would take into consideration different types of responses.
> By not giving up consistency within these contexts (within - not between) then I think that our lives as developers, and as users, are markedly simpler (so less cost) - let alone the cost of monitoring, troubleshooting, support, etc... none of which is trivial. I'm not saying to never give this up - but that it is a very reasonable choice in a lot of situations to not do so, and that large benefits can still be had.
Yes, it needs to be a business decision in terms of what is the cost of having a feature if not the entire system down. No doubt. That is why we don't have a green light for this yet. But shouldn't that be always the case?
Cheers,
Nuno
Raoul Duke
<ian.hammo...@gmail.com> wrote:
> As part of that I think that it would be worth outlining what you need
> to compensate for in each combination of the various techniques i.e.
> if you choose CQRS with Full Consistency what do you need to win/lose,
> what are your compensation strategies for that. I think that would
> help folks deal with constraints that they have, select an appropriate
> response, and understand the cost of what they have chosen.
+lots.
Udi Dahan
> That said, I like eventual consistency because it forces you to ask questions and better understand the domain.
Big +1 from me.
-- Udi Dahan
No virus
found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.864 / Virus Database: 271.1.1/3235 - Release Date: 11/03/10
08:36:00
Simon Harris
> the picture. My understanding from what I see Greg talk about is that
> capturing the transactional nature of the domain is the driver behind
> event sourcing not scaling (although that you can use it to scale is
> of utility). That is why I would tend to pitch event sourcing as a
> 'how does Amazon' scale' is I think something of a red-herring.
Hear hear. Whatever anyone elses reasons for adopting ES, mine has nothing to do with scaling and everything to do with capturing the semantics and intent of the domain. I write code in the hope that it captures the language, intent, and understanding of the domain and it's experts. In ES I see and experience a way (not the only way) to elegantly do the same at a fundamental level. When my code is composed of methods that reflect the way i interpret the domain operates, it helps explain and understand how to use it now and in the future. When the effect of those operations are captured in a similarly semantic way, it helps explain and understand how the system was used in the past. As mentioned previously, i also like that the events can act as a protocol when communicating this activity and they do so in a semantic way. I cannot deny that in place updates work sufficiently well for, and reflect the mental models of many people just as one cannot deny that I find ES to be better for me.
Simon Harris
> Hi Simon.
>
>> For me, the conceptual simplicity of the architecture (ignoring eventual consistency concerns) was and still is highly attractive. I'm finding it much more closely aligns with my mental model than other solutions i have attempted in the past.
>
> Don't understand why CQRS is so simple and MVC so complicated.
I never made the implied assertion.
Nuno Lopes
>>>
>>> Hmmm i must beg to differ. I don't need eventual consistency but if i consider events as the protocol, it provides me with great opportunity to separate the construction of the UI from that of the core domain model.
>>
>>
>> True. But for that purpose you can also consider implementation around MVC and Presentation Model.
>
> Indeed I can use one of many approaches however none are trivial, all have with pros and cons thus I cannot see a basis for concluding that one in particular is a waste. For me, the conceptual simplicity of the architecture (ignoring eventual consistency concerns) was and still is highly attractive. I'm finding it much more closely aligns with my mental model than other solutions i have attempted in the past.
I guess you made the statement in comparison so I assumed your answer was also in comparison.
I should probably state that the context of my assessment that concluded in "waste" was one where CQRS is applied to fully consistent systems not in an eventually consistent. In which case I mentioned other patterns above that in my view offer simpler an alternatives. We could also mention NakedObjects.
I've been developing web apps since Mosaic. Never felt the need for CQRS in relationship to the UI. But I did felt about MVC.
> Hear hear. Whatever anyone elses reasons for adopting ES, mine has nothing to do with scaling and everything to do with capturing the semantics and intent of the domain.
Mine is in allowing the user making more informed decision iff they feel the need. In some domains is actually a requirement, other not so much. Eventually consistent systems just enforces the need in some cases, in other cases becomes mandatory.
Nuno
>> Hi Simon.
>>
>>> For me, the conceptual simplicity of the architecture (ignoring eventual consistency concerns) was and still is highly attractive. I'm finding it much more closely aligns with my mental model than other solutions i have attempted in the past.
>>
>> Don't understand why CQRS is so simple and MVC so complicated.
>
> I never made the implied assertion. - Simon
Nuno Lopes
> That said, I like eventual consistency because it forces you to ask questions and better understand the domain.Big +1 from me.