Disadvantages Of CQRS?
alphadogg
Everything has tradeoffs and no presentation sits well if it seems to just be cheerleading for something. What would you say is CQRS' disadvantages? (And, by CQRS, I do mean the design pattern, and not event sourcing, DDD or other mixins people commonly use along with CQRS.)
So far, I have seen:
- Newness/unfamiliarity in most development ecosystems.
- Added complexity in the user interface. (It's harder to design an asynchronous interface.)
- If your CQRSing is more than just "logical", you may have added:
- complexity in the physical implementation due to an increase in technologies used.
- added potential of data inconsistency.
√iktor Klang
I am putting together a presentation for a lunch-and-learn for my local team on CQRS.
Everything has tradeoffs and no presentation sits well if it seems to just be cheerleading for something. What would you say is CQRS' disadvantages? (And, by CQRS, I do mean the design pattern, and not event sourcing, DDD or other mixins people commonly use along with CQRS.)
So far, I have seen:
- Newness/unfamiliarity in most development ecosystems.
- Added complexity in the user interface. (It's harder to design an asynchronous interface.)
- If your CQRSing is more than just "logical", you may have added:
- complexity in the physical implementation due to an increase in technologies used.
- added potential of data inconsistency.
Anything wrong, or more?
For me the biggest drawback is that it's fairly complex to port legacy code.
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Milo Hyson
I'm not sure I follow your second point (about the UI). It is my
understanding that CQRS need not be asynchronous. A UI could, for
example, send a command to one interface, block until completion, and
then read any results from a second interface. As far as I know, that
would still be consistent with basic CQRS principles.
- Milo
On Feb 28, 2:05 pm, alphadogg <alphad...@gmail.com> wrote:
> I am putting together a presentation for a lunch-and-learn for my local team
> on CQRS.
>
> Everything has tradeoffs and no presentation sits well if it seems to just
> be cheerleading for something. What would you say is CQRS' disadvantages?
> (And, by CQRS, I do mean the design pattern, and not event sourcing, DDD or
> other mixins people commonly use along with CQRS.)
>
> So far, I have seen:
>
> - Added complexity in the user interface. (It's harder to design an
> asynchronous interface.)
> - If your CQRSing is more than just "logical", you may have added:
> - complexity in the physical implementation due to an increase in
> technologies used.
> - added potential of data inconsistency.
>
> Anything wrong, or more?
mynkow
Greg Young
with most of what is written here but without context cannot form a
response.
On Monday, February 28, 2011, mynkow <myn...@gmail.com> wrote:
> True, but then you better go for a standard CRUD model.
> Your UI should do the validation for the objects and try to pass valid data with the command. After that sends the command and that is it. Do not wait the command to be completed and refresh from the read model, never. You should know that cqrs applies to 5-10% of the projects, so if you tell us more we can help you.
--
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention
Tom Janssens
vs advantages:
- Explicit messages add a lot of protocol (LOC) <-> Making everything
explicit and decoupled makes refactoring a breeze
- It can be difficult to model AR's and saga's <-> CQRS forces you to
think about and fully understand your domain
- Eventual consistency is introduced<-> Eventual consistency is always
there, CQRS makes it more explicit and allows you to prioritize things
- Lasagna code <-> you have 3 distinct problem domains : business
domain, UI and viewmodel building => mythical man-month effect is
reduced & you can have different experts for each problem domain
- message bus vs direct invokes <-> possibility to postpone and/or
remote invocations, BDD tests are a breeeze
Do you really need CQRS to build your app ? Here is my opinion:
When I get started on a new app, I usually do not start with CQRS, but
with a task-based UI and CQS (command-query separation) using
convention based M-V-VM-C. (mapping between "V/VM" and "V/Controller
method invocation" is based on conventions).
I use an incremental approach for development:
In the beginning my controller methods usually look like this (think
active record-like for the command part):
* Query: return new view(Repo.Load<SomeViewModel>())
* Command: modify POCO and redirect to query method
If my controller code gets to complex, I start using a domain service
for the command part, so the code starts to look like this:
* Query: return new view(Repo.Load<SomeViewModel>())
* Command: invoke domainservice and redirect to query method
If my domain service starts getting to complex, I start using true DDD
combined with CQRS (I convert my domain service interface into
explicit commands and my poco's into AR's, introduce events and
viewmodel builders etc).
* Query: return new view(Repo.Load<SomeViewModel>())
* Command: bus.Handle(new somecommand()) and redirect to query method
This allows me to ship code quite fast, while keeping future
extensions should have minimal impact...
Side note / off topic: IMHO agile/lean is not about a certain
methodology (think SCRUM f.e.), but about continuously providing
business value in small incremental steps using the most efficient
approach that is possible.
This homegrown approach is my baby, and I am pretty confident about
it... Off course, based on your experiences, opinions may differ. ;-)
√iktor Klang
I disagree on your CRUD remark, but these are IMHO the major drawbacks
vs advantages:
- Explicit messages add a lot of protocol (LOC) <-> Making everything
explicit and decoupled makes refactoring a breeze
That's a language thing, defining a command or event in Scala is 1 LoC.
- It can be difficult to model AR's and saga's <-> CQRS forces you to
think about and fully understand your domain
Depends on language, Sagas are very easily modeled as Actors.
- Eventual consistency is introduced<-> Eventual consistency is always
there, CQRS makes it more explicit and allows you to prioritize things
+1
- Lasagna code <-> you have 3 distinct problem domains : business
domain, UI and viewmodel building => mythical man-month effect is
reduced & you can have different experts for each problem domain
+1
- message bus vs direct invokes <-> possibility to postpone and/or
remote invocations, BDD tests are a breeeze
+1
Derick Schoonbee
that one can face) is: The "fear of change".
This applies when you want to sell CQRS(+ES) to the stakeholders since
is not the >>traditional<< 3-tier or layered architecture people are
used to. (You can add some other reasons too)
Yes, people like new things but want "something tried and save" to
mitigate risk, which is not always the way people / decision makers
view CQRS (Oooh... is this new?).
Naturally it depends on the details of the project like if it is a POC
or business critical application
√iktor Klang
One point I see as a possible disadvantage (since this is something
that one can face) is: The "fear of change".
How do you mitigate that?
This applies when you want to sell CQRS(+ES) to the stakeholders since
is not the >>traditional<< 3-tier or layered architecture people are
used to. (You can add some other reasons too)
From the reactions I've had following presentations is unanimously positive, atleast from developers.
And I bet most of them are from an N-tier background.
Yes, people like new things but want "something tried and save" to
mitigate risk, which is not always the way people / decision makers
view CQRS (Oooh... is this new?).
CQRS is far from new.
Nuno Lopes
> - It can be difficult to model AR's and saga's <-> CQRS forces you to
> think about and fully understand your domain
I disagree. That is one of its strengths but also one of its flaws.
Cheers,
Nuno
Nuno Lopes
> From the reactions I've had following presentations is unanimously positive, atleast from developers.
> And I bet most of them are from an N-tier background.
That is because most developers don't really understand the domain. They know about architecture though.
In fact, in the big ball of mud of things CQRS has been applied over and over.
IMHO what makes interesting in Greg's and Udi's (where is he by the way, we miss him here) view of this stuff, they not only bring a domain driven design perspective to it (Intelligent domain objects and aggregates), but also adopt a pragmatic perspective to the task. Naming messages is IMHO between events and command is the least valuable assertion. We have been doing that for years, yet the mud seamed to be unavoidable in a lot of projects.
I should point out, that any data/fact integration task is by itself eventually consistent.
What we still lack, at least I do and have been thinking about it, is a complete practical modeling and design theory in designing business facts around domain events intertwined with concepts such as Entities and Aggregates has processing engines. On top of this, we also need to define the logical mechanisms that we can use to manage eventual consistency between fact replicas considering multiple time lines.
This considering events are ubiquitous artifacts in CQRS.
So if there are any drawbacks, I would say immaturity of the model based on my experience, yet a lot of practical lessons to learn and to apply in real life. We are still steps away to take the most of CQRS in our solutions without resorting to things that work but still leaves me with a taste of an hack.
Cheers,
Nuno
Andrea
Derick Schoonbee
"small" point: Just something to keep in mind. Not really something
you can do other than educate. (Which is the purpose of presenting
CQRS to developers/stake holders. Like this thread, addressing/looking
at disadvantages.)
I see it as selling a "new idea" vs selling "something known" to use
in a particular project. Developers/techies like new cool stuff which
can scare the business sometimes ;) CQRS looks like something
different but once you see what's its about it makes perfect sense.
> CQRS is far from new.
(and others)... that's changing every day!
On Mar 1, 10:52 am, √iktor Klang <viktor.kl...@gmail.com> wrote:
> On Tue, Mar 1, 2011 at 10:46 AM, Derick Schoonbee <
>
Nuno Lopes
> Maybe a good aproach would be that some people try to write a blog post about it so its easier to understand what each one sees as disadvantages
> this is a very good question but hard to see the real problems
That is the first sign that there are problems :) We are still learning ... I think.
It is very difficult to measure the impact of business rule fragmentation (implement some in the UI, a bit the Entity another in the Aggregate and some other in a Saga). Usually means loosing business competitiveness, in the medium to long run.
This might not be a problems still, considering that most IT solutions are relatively short lived. Take a startup, in might flop in less then 3 years.
Cheers,
Nuno
Tom Janssens
> > think about and fully understand your domain
>
> I disagree. That is one of its strengths but also one of its flaws.
are stating here ?
Nuno Lopes
>>> - It can be difficult to model AR's and saga's <-> CQRS forces you to
>>> think about and fully understand your domain
I disagree that it necessarily forces us to have a deeper insight of the domain. This can can be flaw and a strength in context. It is a Strength because its is versatile, but his also a weakness since it can lead us to a false sense for understanding.
ARs are design constructs. They are not difficult to model if we know about domain modeling and DDD.
I remember Udi posts and his strong emphasis on Bounded Contexts along with Sagas et all. Unfortunately he was reusing this term from DDD with his own mindset.
The concept of Bounded Context in DDD is mostly driven by managing complexity of ones solution. It does not give a baseline to discuss what his was is not part of a bounded context.
For instance, he considered a Shopping Cart defining a Bounded Context and Order as defining another BC in itself as far as I remember. He did this almost intuitively as most experienced modelers do.
Bounded Context: http://domaindrivendesign.org/node/91
His variant was mostly concerned with the UL and in particular homonymous concepts and related challenges. Unfortunately this was lost in definitions.
The key term of Bounded Context, is Context. His context was the UL and he used this to establish greater insights on the way he designed a domain model. It is hard to establish what is a domain model or several in one single solution especially when we articulate multiple Bounded Contexts with one single broad activity, say a Sale.
Me and him have disagreed in some things, but not in most of the things as far as I remember. Unfortunately an online forum, tends to drag things that lack consensus, becoming more relevant rather then consensus.
Cheers,
Nuno
Nuno Lopes
Nuno Lopes
Sorry I'll try again, I understand that the interpretation could go both ways.
- It can be difficult to model AR's and saga's <-> CQRS forces you tothink about and fully understand your domain
I disagree that it necessarily forces us to have a deeper insight of the domain. This can can be flaw and a strength in context. It is a Strength because its is versatile, but his also a weakness since it can lead us to a false sense for understanding.
ARs are design constructs. They are not difficult to model if we know about domain modeling and DDD.
I remember Udi posts and his strong emphasis on Bounded Contexts along with Sagas et all. Unfortunately he was reusing this term from DDD with his own mindset.
The concept of Bounded Context in DDD is mostly driven by managing complexity of ones solution. It does not give a baseline to discuss what his was is not part of a bounded context.
For instance, he considered a Shopping Cart defining a Bounded Context and Order as defining another BC in itself as far as I remember. He did this almost intuitively as most experienced modelers do.
Bounded Context: http://domaindrivendesign.org/node/91
His variant was mostly concerned with the UL and in particular homonymous concepts and related challenges. Unfortunately this was lost in definitions.
The key term of Bounded Context, is Context. His context was the UL and he used this to establish greater insights on the way he designed a domain model. It is hard to establish what is a domain model or several in one single solution especially when we articulate multiple Bounded Contexts with one single broad activity, say a Sale.
Me and him have disagreed in some things, but not in most of the things as far as I remember. Unfortunately an online forum, tends to drag things that lack consensus, becoming more relevant rather then consensus.
Cheers,
Nuno
On Mar 1, 2011, at 11:13 AM, Tom Janssens wrote:- It can be difficult to model AR's and saga's <-> CQRS forces you tothink about and fully understand your domainI disagree. That is one of its strengths but also one of its flaws.Could you be a bit more elaborate on this; I do not quite get what youare stating here ?On 1 mrt, 11:44, Nuno Lopes <nbplo...@gmail.com> wrote:- It can be difficult to model AR's and saga's <-> CQRS forces you tothink about and fully understand your domainI disagree. That is one of its strengths but also one of its flaws.Cheers,Nuno
Tom Janssens
> Let me explain in more detail the light of a Shopping Cart, Product, Order and other related business concepts.
I do not see what is the problem here, are bounded contexts not
relevant with the following statement ?
>>> - It can be difficult to model AR's and saga's <-> CQRS forces you to
>>> think about and fully understand your domain
a BC : https://gist.github.com/d15b6cf4f44956d059bf
Greg Young
Bounded Context is like comparing the travel qualities of a train vs
the tastiness of a steak.
--
Tom Janssens
(Assumption: you use BDD stories to specify your domain functionality
by example)
In my stories the scope of a single BDD story *usually* respects the
boundaries of a single bounded context...
Please note that English is not my mother tongue, but I am hoping to
get the message through.
(The travel qualities of a train can be elevated by providing a very
tasty steak for lunch during the ride ;-) )
Greg Young
We could say that a story is usually within a BC but as you mention
below a steak can be had while traveling on a train, that does not
imply some direct relationship between them.
Tom Janssens
> below a steak can be had while traveling on a train, that does not
> imply some direct relationship between them.
between them, it should not be mentioned in the story, since it is
irrelevant (i.e. it does not specify behavior, so it is redundant in
the scenario).
Nuno Lopes
> I read this email as being very confused. Comparing a BDD story to a
> Bounded Context is like comparing the travel qualities of a train vs
> the tastiness of a steak.
That was no my intent. My intent was to demonstrate that CQRS does not have any position regarding conceptual boundaries in terms of the UL. Wether we use Bounded Context, Use Cases, BDD Stories or artifacts to describe them. Its is not a CQRS facet neither it makes it explicit.
Something that is paramount to fully understand the domain.
I have not doupt what a Bounded Context is in DDD terms. Indeed I emphasized an old exchange of ideas we had in the DDD forum around the use of BCs by Udi. Which was not inline with DDD as it seamed back then.
Still the point he did was indeed important I think to CQRS, name it according to the preferred discipline.
Cheers,
Nuno
Nuno Lopes
You can correct me of I'm wrong, I'm a BDD noob yet not from other similar practices.
The business boundaries of a BDD Story can be say one of a Sale. Yet the story can cross cut several BCs.
When we refine the story, adding more detail and eventually factoring it out into smaller stories we may end up with each of these smaller stories be within one BC. We might discover new BCs etc.
Still the initial story defines a process flow that encompass multiple BCs.
On another note we might have an initial equation of what our BCs are. Based on experience and by evaluating legacy systems, but others emerges from the complexity of the problem domain as defined in stories and some are actually eliminated.
All in all I'm trying to understand this phrase of yours that I don't agree with yet other experiences are totally valid :)
>>>>>>>>>> - It can be difficult to model AR's and saga's <-> CQRS forces you to
>>>>>>>>>> think about and fully understand your domain
I have a hard time imagining how the separation of views from the model, commands (present/future) from queries and domain events (past), together with a BUS (even if abstract) forces one to think about the domain in ways more simple domain modeling DDD. Maybe with an example would be easier.
I've seen people trying to model a Shopping Cart around the concept of Order, guess what it does not work well. It clutters ones code and reduces flexibility. The temptation is great because the items in a Shopping Cart are quite similar to OrderLines in an Order.
You can imagine that in these cases people are trying to model the Shopping Cart simply as a State of an Order (or flag).
Adding commands, queries, domain events and a BUS it does not help at all. In the end of the day we could still have ShoppingCartSubmitted (by simply changing the State of the Order object), OrderSubmitted and so on. The data in these events could even be extremely similar.
The important thing to realize is that the clockwork of a Shopping Cart is different then one of an Order even when they look similar. In other words, the context of its use is different. Hence they need to be distinct Aggregates.
Cheers,
Nuno
Tom Janssens
* As a xxx
* I want yyy
* To be able to zzz
* In order to aaa
Your story scope should *usually* match only one BC boundary; if your
story crosses boundaries, you are usually trying to specify too much
behavior in a single story, or you are mentioning details which are
not modifying behavior. (think SOC for BDD stories)
> I have a hard time imagining how the separation of views from the model, commands (present/future) from queries and domain events (past), together with a BUS (even if abstract) forces one to think about the domain in ways more simple domain modeling DDD. Maybe with an example would be easier.
(think SOC again)
>
> meer lezen »
kjetilk
your team, your environment, and everything surrounding your
development group. I would say that for most teams the biggest
disadvantage is the cost of learning. I do not have any numbers to
back me up here, but based on my own experience and gut feeling the
waste majority of developers out there work with layered CRUD-
architecture where the UI talks to some data access layer (maybe
passing through some services / business layer on their way), which
again talks to a relational database designed in a more or less
normalized way.
Moving from this over to CQRS, you will probably introduce concepts
like DDD, message bus, separate databases designed for read and write
(or maybe even ES or object databases), explicit commands, explicit
events, task-based UI, and sagas - it is not an easy move! It takes a
lot of time and a lot effort from the whole team to get up to speed on
these concepts.
Yes, there are frameworks/libraries, examples, forums, blog posts, and
books on the various concepts out there, but none of the will give you
a blueprint on how you should develop your solution. The cost of
learning is by far the most expensive part of jumping into CQRS from
my experience.
The biggest advantage on the other hand, is the 'unlimited'
scalability you gain. So if your project has high demands on the
scalability side, taking the learning cost might be well worth it. But
do not underestimate it and be open and earnest on this part to your
product owners / customers / stakeholders.
Then again; if your team is already familiar with DDD, messaging and
task-based UI, the learning cost will be far less. But as I said; I do
not believe this is the case for the vast majority of developers out
there. It all depends....
- Kjetil Klaussen
On Feb 28, 11:05 pm, alphadogg <alphad...@gmail.com> wrote:
> I am putting together a presentation for a lunch-and-learn for my local team
> on CQRS.
Nuno Lopes
ok, this was pars pro toto; imho CQRS leverages proper DDD design
(think SOC again)
√iktor Klang
ok, this was pars pro toto; imho CQRS leverages proper DDD design
(think SOC again)Yes. CQRS is part of DDD. IMHO Talking about it without DDD mindset all we are talking is messages and pipes along with cache. Nothing new. MVC applied on a network scale.
I disagree, if you use CQRS w/o DDD, but with ES you _can_ have an immutable domain model that doesn't need to follow DDD.
What establishes a framework for reasoning about the domain into our designs is DDD.
That means that you can never have a CQRS framework if there has to be bizcode to be CQRS.
If you want a buzz concept, CQRS + DDD = Domain Driven Messaging or Networking.
Nice buzz
This is just my opinion.Cheers,
Nuno
Nuno Lopes
Sent from my iPad
Rinat Abdullin
Nuno Lopes
Hi Nuno,Wasn't DDD + CQRS + etc == DDDD (aka distributed DDD)?Rinat
.... if you use CQRS w/o DDD, but with ES ... - Klang
Rinat Abdullin
bodrin
IMHO CQRS gives you a vertical scaling for the domain BC even if you have no partitioning and a horizontal scaling for the view/read BC if have eventual consistency.
Nuno Lopes
> Actually, using CQRS/DDD without ES and with domain events is what I'm currently doing in production (we're migrating from the DTO world).
http://martinfowler.com/eaaDev/DomainEvent.html
If you are using Greg's ES style. The Aggregate works as a simple event processor. Consuming external and self generated events (Greg's style) . It extends the EP by also generating events.
http://martinfowler.com/eaaDev/EventSourcing.html
Cheers,
Nuno
Rinat Abdullin
Nuno Lopes
I have said that I can't envision Domain Events without some sort of ES. You have said that you use Domain Events without ES, I'm trying to understand how. The concept of ES and Domain Events overlap by definition.
I honestly thought you where using Event Backlogs, aka Event Stores.
Event Sourcing is not about persisting objects as a stream of events as you have written here: http://abdullin.com/journal/2010/11/16/key-cqrs-ingredient.html
We can discuss Udi's use of Domain Events though. I think that NServiceBus might make the backlog transparent by default while allowing the developer to configure the system so that events can be replayed from the backlog or even analyzed when needed. I like most of his way of materializing this in the framework.
Having said this Im not a fan of this article regarding the use of Domain Events: http://www.udidahan.com/2009/06/14/domain-events-salvation/
It seams to be describing a generic event handling mechanism similar to C#, yet instead of having observers over entities, we have observers of a registry of events to which he calls Domain Events.
I think that this is powerful, nevertheless don't see that the article makes such a good case for Domain Events.
Cheers,
Nuno
Rinat Abdullin
Best wishes,
Nuno Lopes
I re-read the code of Udi's article let retract.
The closest you can get to Domain Events with Udi article his class DomainEvents works has a in process event backlog (Event Log or Domain Log, it does not matter). Then he uses the Observer Pattern to notify Observers (handlers) of changes in state per type of Domain Event. Observers can be anything, including something like Handler Classes that can translate the event to another Aggregate. His Handlers work as EP (Event Processors)
The Observer Pattern is a variant of a more broad concept of Publish/Subscribe.
Ok, you may not be using ES currently.
> Event sourcing == persistence approach in which entity is persisted as a stream of events leading to it's current state.
That is not the industry definition of ES, currently. But I can see that is one view on the matter, valid has any.
> Domain event == event that has been dispatched by AR into the messaging infrastructure and is capable of crossing domain boundaries (if we directly publish our persistence events, they need to be enriched with AR info either within message body or within transport headers)
Check Erics Cargo sample. it's much more then that. Domain Events in DDD can be part of the domain model in his example and is not dependent on a publish/subscribe at all. In this case it is close to event sourcing and can be augmented up to Greg's approach.
I see more value in using Domain Events this way in terms of domain design rather then the above domain event dispatching mechanism based on publish/subscribe.
So yes, you may use Domain Events without ES, but in this case I don't see what the word Domain adds to the Event equation in CQRS. Checks Erics sample, it does add to the model (LOAD CARGO, UNLOAD CARGO, etc etc).
Cheers,
Nuno
Rinat Abdullin
Nuno Lopes
> The difference between our terminology probably is showing up because in my distributed world, there is no "The Application", but rather a mesh of various components operating within different consistency boundaries, failure modes and data centers.
We also don't have the Application if not for a URL and what the users perceive to be. We are quite distributed and heterogenous. Having said this I see your point.
Cheers,
Nuno
@seagile
Greg Young
when using event sourcing.
As I travel around I often ask for a show of hands of how many people
process more than 10 transactions per second. I get very few, I can
process 10 transactions per second on my cell phone.
You are correct though in that the introduction of analysis is the
largest cost associated. Introducing analysis on a project that really
doesn't need it can be a recipe for disaster.
Greg
--
alphadogg
√iktor Klang wrote:
> I think ES in itself has more intrinsic value than just CQRS, so not using
> it if you have the opportunity is a shame really.
Well, I am looking specifically at CQRS. At subsequent lunch-and-
learns, I will cover the other concepts.
> > Depends on your tooling, most times it can actually become simpler because you have a separation of the reader and the writer in the UI
However, the asynchronous calls and how to handle them is definitely
not the norm, wouldn't you say?
> >
> > -
> > - complexity in the physical implementation due to an increase in
> > technologies used.
> >
> you don't want to.
Right. That's why I used an if...then.
> >
> > - added potential of data inconsistency.
> >
Well, from the user's perspective, yes. But, from the system's
perspective, data must be consistent or "eventually consistent", as it
is often said. However, by dividing the read and write sides, you
introduce a point of failure which can ruin consistency if you don't
plan for it... if necessary.
Thanks for your input.
alphadogg
complicated as full-on asynch calls, than the usual request-block-
reply approach...
Milo Hyson wrote:
> alphadogg,
>
> I'm not sure I follow your second point (about the UI). It is my
> understanding that CQRS need not be asynchronous. A UI could, for
> example, send a command to one interface, block until completion, and
> then read any results from a second interface. As far as I know, that
> would still be consistent with basic CQRS principles.
>
> - Milo
> On Feb 28, 2:05 pm, alphadogg <alphad...@gmail.com> wrote:
> > I am putting together a presentation for a lunch-and-learn for my local team
> > on CQRS.
> >
> > be cheerleading for something. What would you say is CQRS' disadvantages?
> > (And, by CQRS, I do mean the design pattern, and not event sourcing, DDD or
> > other mixins people commonly use along with CQRS.)
> >
> > So far, I have seen:
> >
> > - Newness/unfamiliarity in most development ecosystems.
> > - Added complexity in the user interface. (It's harder to design an
> > asynchronous interface.)
> > - complexity in the physical implementation due to an increase in
> > technologies used.
> >
√iktor Klang
Well, I am looking specifically at CQRS. At subsequent lunch-and-
√iktor Klang wrote:
> I think ES in itself has more intrinsic value than just CQRS, so not using
> it if you have the opportunity is a shame really.
learns, I will cover the other concepts.
However, the asynchronous calls and how to handle them is definitely
> > Depends on your tooling, most times it can actually become simpler because you have a separation of the reader and the writer in the UI
not the norm, wouldn't you say?
I'm biased since I do async stuff more than sync.
> >
> > -
> > - If your CQRSing is more than just "logical", you may have added:
> > - complexity in the physical implementation due to an increase inRight. That's why I used an if...then.
> > technologies used.
> >
> > This is highly situational, you don't have to add any extra technologies if
> you don't want to.
That was just fictional, you may as well say:
If your CQRSing is more than just "logical", you may have added:
> >
> > - added potential of data inconsistency.
> >Well, from the user's perspective, yes. But, from the system's
> > That's the entire thing with CQRS, data is always inconsistent
perspective, data must be consistent or "eventually consistent", as it
is often said.
The key is: consistent in what regard?
However, by dividing the read and write sides, you
introduce a point of failure which can ruin consistency if you don't
plan for it... if necessary.
It's only inconsistent if the expectations promised isn't true.
Thanks for your input.
My pleasure
alphadogg
> That was just fictional, you may as well say:
>
> If your CQRSing is more than just "logical", you may have added:
> - a crapload of spaghetticode mixed with jelly beans
> It's only inconsistent if the expectations promised isn't true.