When not to use CQRS and why

[Hoegge]

I many descriptions of CQRS (and eventsourcing) people (like Fowler and Udi https://initiate.andela.com/event-sourcing-and-cqrs-a-look-at-kafka-e0c1b90d17d8) states that CQRS is definitely not right for a lot of things, actually not that often and that you should be careful about when to apply it. The only real examples on when not to use it I have heard / read is when the problem you try to solve is a primitive problem that fits CRUD perfectly - which is really not suprising. Fowler also says (GOTO2017) that it is a “pattern that seems to correlate a lot with people getting into trouble” and “it is a good pattern when used appropriately” which is not really enlightning. Udi Dahan says: “When to avoid CQRS: Most of the time” - ehm? I’m more inclined towards Greg Youngs attitude - that it actually simplifies most systems (as I perceive him) - we’re not talkin about simple single user ToDo list appplications but enterprise wide systems. I still find hard to find any evidence of when that is and when it is not. From a conceptual point of view, it seems just as simple if not simpler than any other pattern (like CRUD) and in many ways healthier - like Redux in the front end. Isn’t it just because to few people really knows it and have been trained on using it and therefore implements it wrongly? E.g. a lot of developers seems to have a hard time living with eventual consitency even though that is the case in any bigger system and rarely a problem at all in the real world.

Can anybody give a perspective, case stories or substantiate those warnings?

Thanks

[stefan.o...@googlemail.com]

Hi,

any approach can get you in trouble when you don't do things right. For "rather new" approaches, getting into trouble is more likely because the lack of (broad) experience, background, publications, etc.

A lot has happened in the last years, so warning that are a couple of years old should be taken with a grain of salt today.

Plus: the traditional CRUD approach of a monolith mapping everything into a relational database has failed big time, and very often. If you look for it, you will find a fair amount of warnings and criticism about this approach as well. Same story, essentially: you will always find people who have succeeded with something, and people who have failed.

Stefan

-- 

Stefan Priebsch                              The PHP Consulting Company

Co-Founder and Principal Consultant                   https://thePHP.cc

[Peter Hageus]

I think most contexts with complex behaviour benefit from CQRS.

My initial test is modelling a flow as events (often just in my head). If most of the events end with *Created, *Saved, *Updated, *Changed or similar, it’s probably better modelled as CRUD.

/Peter

> --
> You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

[Rickard Öberg]

Hi!

I've been doing "event based" systems for 15 years now. When I look at
non-ES systems I get a headache, they seem incredibly complex to me.
The main new thing I have done personally recently is to add CQRS to
the mix, and have a truly separated write/read model. That really
helped too, but is orthogonal to event sourcing. I don't see any
reason why you would not want to use CQRS pretty much always, even if
you don't use event sourcing (i.e. once aggregate has generated
events, apply them in database right away instead of storing in event
store). It makes everything else in the system just so much easier.

I'm meeting up with Fowler in a few months, and was hoping to get some
clarity on this recommendation of his, because it's been bugging me
too.

/Rickard

2018-03-01 16:39 GMT+08:00 stefan.o.priebsch via DDD/CQRS
<ddd...@googlegroups.com>:

[Hoegge]

Hi Rickard 

Sound interesting and looking forward to what you and Fowler find out, when you meet.

[Greg Young]

There are times it can be "gold plating". As an example writing a simple blog. Event sourcing it sounds like being more complicated than it needs to be. It is more data centric than behaviour centric.

> email to dddcqrs+unsubscribe@googlegroups.com.

> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[Rickard Öberg]

Hey,

True that. But starting from the assumption that "CQRS is the way to
go", and then downscaling, if necessary, is probably a more practical
approach than the other way round.

Part of this is also around the "easy vs simple" argument. Yes, it is
more easy to do what we have always done, but that doesn't necessarily
mean that it is more simple. What we, as an industry, should be aiming
for is both simple AND easy. Once there are more patterns and examples
around how to effectively do CQRS, like Greg's "Simple CQRS" example
project, it becomes more easy to do it, and so the main question (as
it should be) becomes simple vs complex.

/Rickard

>> > email to dddcqrs+u...@googlegroups.com.

>> > Visit this group at https://groups.google.com/group/dddcqrs.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DDD/CQRS" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to dddcqrs+u...@googlegroups.com.

>> Visit this group at https://groups.google.com/group/dddcqrs.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Studying for the Turing test
>

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to dddcqrs+u...@googlegroups.com.

[Greg Young]

Totally agree re simple vs easy (and it was a great talk).

>> > email to dddcqrs+unsubscribe@googlegroups.com.

>> > Visit this group at https://groups.google.com/group/dddcqrs.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DDD/CQRS" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to dddcqrs+unsubscribe@googlegroups.com.

>> Visit this group at https://groups.google.com/group/dddcqrs.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Studying for the Turing test
>
> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to dddcqrs+unsubscribe@googlegroups.com.

> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Jimmy Bogard]

We use CQRS on every project these days. Dozens and dozens of projects, it's had great results. The arguments against CQRS seem to putting up strawmen on CQRS implementations that separate the data stores. That's just one possible implementation. You can just have two objects where once there was one. I don't know why CQRS got conflated with one particular implementation but it's rather unfortunate. The pattern itself is highly applicable in my experience.

We don't see many "CRUD" apps, but do see areas of an application/system that are more inclined to CRUD. But I find it better to be consistent in your approach in an application.

Event sourcing is a completely separate discussion and should also not be conflated with CQRS. Kinda like containers and microservices.

[Rickard Öberg]

Hi Jimmy,

Just curious, did you (like me) start with Greg's "Simple CQRS"
example, or did you find another starting point, or do it from
scratch?

/Rickard

>> email to dddcqrs+u...@googlegroups.com.

>> Visit this group at https://groups.google.com/group/dddcqrs.
>> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to dddcqrs+u...@googlegroups.com.

[Alexandre Potvin Latreille]

Jimmy: What is your approach to maintain the read model without events?

[Rickard Öberg]

On Wed, Sep 12, 2018 at 11:21 PM Alexandre Potvin Latreille
<alexandre.pot...@gmail.com> wrote:
>
> Jimmy: What is your approach to maintain the read model without events?

To be clear, just because he's not using event sourcing does not
necessarily mean he is not using events. A command can be sent to an
aggregate, converted to events, and then immediately applied to a
standard database, clustered or not. You don't have to change any
infrastructure to apply CQRS, but with EventSourcing you kinda do.

/Rickard

[Morten H Pedersen]

Hi Rickard,

Did you talk to Fowler about this?

/Morten

You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/3Ys3OawSTTM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Greg Young]

Reuilding/recreating read models/supporting multiple read models (in schema/geo location/etc) becomes vastly more complex in this case though ;-)

[Rickard Öberg]

Hi Morten,

I did, yeah. Can't say I learned anything new, it was a bit vague,
with the usual suspects of technical issues, not being used to it,
having domains that aren't applicable, and such.

/Rickard

[Rickard Öberg]

Oh, totally, I would see this more of a case where you can’t change infrastructure, but you can own how the app is structured. If you have the option to actually add event sourcing, go for it.

Sent from my iPad

[Thomas Eyde]

How will you get used to CQRS if you never use it?

Arguments about the domain is not that complex, CRUD is a better fit, and so on are straw-man arguments. Because, how do you know if a domain is not complex? For how long will it stay that way? And how do you get experience with CQRS (and event sourcing) if you decide to never use it?

We have to learn, so why not pick the simple domain and lower the risk while doing it?

Reminds me of an assignment where the domain was parking tickets. At some point the business decided we would need logs. One would show the history of changes for an entity, an other would show all changes done by a case handler.

How do you create a log that contains different things like:

- Ann uploaded 2 images to ticket #123

- Ruth deleted 1 image to ticket #123

- Eric changed amount from $90 to $50 on ticket #123

- Ruth shredded ticket #123

If we know up front all the things this log would ever show, then we could implement something CRUD style. But in this case, the business didn't know other than 'we need it for future checks and auditing'.

I can't see a better fit for event sourcing, even if you don't want the event store to be source of truth:

- Generate the events

- Use them to update the CRUD store

- Save them

- Replay / project them whenever the logging requirements change

But I failed to convince my tech-lead, because 'it was so much code'. And until C# get records, it is. 

--Thomas