Architecture Weekly #94 - 26th September 2022
Discover more from Architecture Weekly
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:
I also had a discussion on Twitter about the complexity attached to CQRS.
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?
Feel invited!
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:
Benek Lisefski - The pros and cons of Big Design Up Front — and what I do instead
Jon Moore and Marty Cagan - Changing How You Decide Which Problems To Solve
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!
Cheers
Oskar
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
Adam Tal - First make the change easy, then make the easy change
Benek Lisefski - The pros and cons of Big Design Up Front — and what I do instead
Forrest Brazeal - The cloud billing risk that scares me most as a developer
Stefan Tilkov: Why software architects fail – and what to do about it
Ralph Kimball - Design Tip #51: Latest Thinking On Time Dimension Tables
Jon Moore and Marty Cagan - Changing How You Decide Which Problems To Solve
Databases
Dmitry Narizhnykh - PostgreSQL Change Data Capture and Golang Sample Code
Andrzej Ludwikowski - Reactive Event Sourcing benchmarks, part 2: PostgreSQL
DevOps
Frontend
Testing
Java
InfoQ - Java 19 Delivers Features for Projects Loom, Panama and Amber
Deepu K Sasidharan - What the Heck Is Project Loom for Java?
.NET
Martin Thwaites - Distributed Tracing in .NET 6 using OpenTelemetry
Michal Strehovský - PublishAotCompressed - Compresses the publish AOT compilation result
dnSkpyEx - Unofficial revival of the well known .NET debugger and assembly editor, dnSpy
TypeScript
Windows
Management
Oskar Dudycz - On the importance of setting boundaries in team management
Ben Matthews - Does high velocity lead to burnout? That may be the wrong question to ask