Architecture Weekly #94 - 26th September 2022
Welcome to the new week!
There are a few hills I could die on in tech discussions. Both are related to confusing explanations of the simple concepts: CQRS and Event Sourcing.
Recently I read yet another terrible take about them both. This time from AWS:
All of that made me create such a meme.
Unfortunately, most of the material shows a skewed perspective about CQRS, not the original definition. CQRS is about separating behaviours in your architecture to writes and reads. It's about focusing on the business operations and ensuring that "writes" (so business logic) are separated from the read operations. That's not related to messaging, event sourcing, eventual consistency, etc. It's about making clear operation intentions and segregating them. I wrote longer about the common myths in my article:
Today at 4 PM CEST, we’ll have the next webinar for paid subscribers community. We’ll discuss:
Why would someone consider using CQRS instead of CRUD?
If there’s the truth in myths like: CQRS needs multiple databases, it is about messaging tools and brings eventual consistency.
Is CQRS more complex, and is work going slower than in CRUD?
What are the benefits and challenges?
I’m right now mostly recognised for the event-driven approach. Yet, that’s only one side of my story. Majority of the last 10 years, I spent as a team leader.
In my last article, I shared why I think strong boundaries are one of the most critical tools in management. I also explained what the maxim of the Polish football coach has to do with that.
Thinking for yourself and questioning authorities is one of the most important aspects of proper design. Too often, we’re so focused on our first thought or habits that we’re not even checking if there’s a better alternative. Routine kills innovation and also can drive us to dangerous cliches. On my teams, I always demanded explanations of the thrown-away alternative solutions. If there were none, that usually meant that team didn’t do the homework. Check more about that in:
If you’d like to see how lousy reasoning and lack of challenging discussion may end up, read:
Nowadays, if we’re not thinking upfront, our pockets may be hit immediately. In one of my past projects, we were thinking about using DynamoDB. It provides superb latency and matched our data design, yet we didn’t use it in the end. It appeared that using DocumentDB would be good enough for our case and much cheaper. Read more about such dilemmas in:
We’re saying that nothing is lost on the Internet. It may appear soon that this statement is not precise anymore. Web Archive is having issues, check more in:
Check, also other links!
p.s. I invite you to join the paid version of Architecture Weekly. It already contains the exclusive Discord channel for subscribers (and my GitHub sponsors), monthly webinars, etc. It is a vibrant space for knowledge sharing. Don’t wait to be a part of it!
p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to Red Cross, the Ukraine humanitarian organisation. You may also consider joining Tech for Ukraine initiative.
Architecture Weekly is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.