#CQRS is not a general purpose style of architecture.

A thread ⬇️
The first time I built a CQRS system… it was in 2006. The term hadn’t be coined yet by Greg (that happened in 2010), but the practice was ubiquitous in finance with tons of high throughput platforms to build or to maintain.
Actually, the first time I’ve used this architecture style was not due to my young skills of tech architect, but rather on a technical constraint.
The technology we were using to publish prices and other market data to our consumers (read side) was not really made to receive more than just subscriptions requests from end users.
The throughputs and scalability capabilities we could have with that tech were great, but it wasn’t made to gather commands from consumers.
Hence we had to use another tech in order to receive configuration change commands for our system (a pricing service). And because we had scalability and affinity constraints, I’ve ended up to split responsibilities of our nodes dealing with commands (a specific write cluster)
from other ones dealing with queries/subscriptions computing the prices on demand and pushing them and following updates to our consumers (the read cluster).

Without even knowing it, it was my first Command & Query Responsibility Segregation experience 😄
Since then, whenever I need to scale and deliver great throughput numbers, I always consider #CQRS

Every time I need to provide a wide range of exposition models for different kind of consumers, I also consider CQRS.
Last but not least. When I’m doing Event Sourcing, I usually end up with CQRS too.
OTOH I’m not one of these people picking #CQRS as default style when they say they want to do #DDDesign .

Even if it is hard, I’m trying to avoid Cargo-cult as much as possible for years, forcing myself to explain why I choose this pattern or that technology.
I’m really against golden hammers in general and try to avoid embracing this mindset as much as possible.

It became a life-time principle. Others may say an obsession 👻
Year after year, I also regularly observed that #CQRS was conflated with event sourcing for lots of dev.

It was the main reason why I wanted to make this talk in 2016 to the MS experiences days in Paris: « CQRS without event sourcing.»

Slides: slideshare.net/ThomasPierrain…
During this session I’ve made a few recommendations, including this one:

« CQRS is not a top-level architecture pattern. Use it for components under stress, but don’t make it a by default pattern for your whole platform / Information System »
I think that the first time I heard this take was from @gregyoung . But it did vibrate with the strong and opiniated « there is no silver bullet » part in me.

Retrospectively, I realized that I didn't really get why it could be a so much bad idea at that time.
And then a few years after, I also realized that publishing too many public/integration events was also a big mistake.
Indeed, you end-up violating the encapsulation of your app/service/API. One should really consider every publicly published event (i.e. integration events between apps/API/Service) as tiny contracts.
Once published, you will hardly get the chance to change them (due to the pressure of your consumers).
And we weren’t the only ones making this mistake at first. Indeed, this has been a major warning communicated by the Event Driven Architecture (EDA) or #DDDesign communities back in the days.
Publishing too many kind of integration events is the best way to end-up with a distributed monolith.

And trust me, you will regret it. Very much.
When doing CQRS badly, there is a risk to publicly expose too many of your events outside of your own app/service/api boundary. One should avoid this at all cost.
Recently, I’ve discussed with people that were so passionate about CQRS that they crossed that red line without even realizing it.
Instead of them building specific read-side models and APIs for their external consumers (i.e. belonging to other Bounded Contexts-BCs) from their CQRS app, they wanted to publicly share a massive part of their #CQRS private models & events with other teams and BCs.
A kind of CQRS “à la carte” allowing others to build their own stuff from other's events, but across plenty of teams.

A kind of “my CQRS is your CQRS”.

Like if CQRS was a top-level architecture pattern…
Their idea was to let external consumers (of their app) build their own read projections from our events.

To do so, they needed to publish a wide spectrum of their event types as public ones on a common message broker so that other teams could clone all their relevant data.
People thinking that “because our coupling is made with events makes it less painful” make a mistake.

One can easily spread the distributed monolith syndrome without even realizing it.
The pain of not being able to refactor & align your code with your domain because you have leaked your initial naive vision towards too many consumers a daily source of frustration.
Encapsulation in OOP was not chosen by chance.

The same applies at the cross-service architectural level. This is also why I have always appreciated the service-oriented approach (now API): it allows you to expose only what others need.

No more no less.
When I understood what they had in mind and tried to achieve, I realized that the warning made by Greg and other was far beyond the message I initially got of “there is no silver bullet” or “you don’t have to systematically pay this accidental complexity for everything”…
The reasons behind are far more important and the risks higher. If you don’t want to build a distributed monolith please read carefully this warning:
« CQRS is not a top-level architecture pattern. Use it for components under stress (or if you need to expose a wide range of exposition models), but don’t make it a by default pattern for your whole platform / Information System »
And don’t let others build their own read projections from your own internal implementation details.
I’ve ended up putting this into a real article


• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with υѕe caѕe drιven

υѕe caѕe drιven Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @tpierrain

Apr 30
Him: last time you were saying that you wanted us to avoid using feature branches. Why? 🔽

Me: I was saying that if you want to move toward Continuous Delivery on that specific software, you’d better aim trunk based development.
H: ok but what you don’t like with branches?

M: Despite what people here are saying, they are very often long-lived. They last more than a day, more than a couple of days. Sometimes a week… When no merge conflict is detected at the end it’s ok.
Bad things happen when there is a merge conflict at the end of the day.

H: Yes, but is it that much painful? Aren’t branches our bread n butter?
Read 33 tweets
Apr 22
Hier a #DevoxxFR , une super session à propos du challenge de releaser sans interruption de service malgré les changements appliqués à nos bases de données relationnelles. Un thread ⬇️
Comment supprimer une colonne, éviter que vos ORMs ne foutent la grouille, éviter les ennuis avec des enums qu’on enrichit… #devoxxFR
Quelques tips & resumé. #devoxxFR
Read 10 tweets
Apr 21
@JulienTopcu commence son show sur OAuth2 expliqué simplement. #devoxxFR
Code unique qui ne change pas ? Des anciens convives arrivent à squatter des chambres. Petits problème de révocation. #DevoxxFR
Petit lexique pour la suite. @JulienTopcu #DevoxxFR
Read 15 tweets
Apr 21
La chance d’avoir pu faire 6 editions de #DevoxxFR sur 10. Un thread ⬇️
2014: mon premier Devoxx avé la moquette 70 (et officiellement ma premiere conf tech en tant que speaker). Avec l’ami Cyrille @_dupdob , on a parlé de programmation reactive, multithreading et de système faible latence.
@morlhon comme gilet rouge dans la salle qui nous chambre comme il faut avant pour nous détendre, supers retours ensuite et gros blast pour nous 2.

(Et 1er talk fait en suivant la méthode Nancy Duarte)
Read 15 tweets
Apr 20
@MarcyChama commence dans l’amphi bleu. #DevoxxFR 🤘🤘🏻🤘🏼🤘🏽🤘🏾🤘🏿 ImageImageImageImage
Bourdieu in da house #devoxxFR grâce à @MarcyChama

On a tous des polos ici 😂 ImageImageImageImage
Brutal fact #devoxxFR @MarcyChama Image
Read 15 tweets
Mar 19
Interesting techniques applied to wrong usages may hurt. A thread 🔽

Seems obvious in lots of domain but not in our Software development field (note: I didn’t talk about software Engineering on purpose)

Me: Why do we have such an increase of infrastructure costs recently?
SRE: It seems that we have a new “OTF env” fad since last month… As a result, more than 70% of our global infrastructure costs are related to non-production environments...

Me: Whaaat? How does this happen? What is “OTF env” exactly?
SRE: OTF envs means “On-The-Fly environments”. It is a mechanism we have recently built in order to setup our entire stack (monolith, new apis, db, message brokers etc) on a K8 dev cluster in a couple of minutes.
Read 19 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!


0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy


3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!