Architecture Weekly #115 - 20th February 2023

Feb 20, 2023

Welcome to the new week!

CQRS is too often pictured as a complicated pattern that adds additional overhead. “Maybe it’s great, but not for my system”. You probably noticed already that I’m fighting with this perception. Almost two weeks ago, I gave a talk at the Swetugg conference showing CQRS with a database (even a single table), ORM, no messaging trying to bust common myths.

I’ve used .NET as an example, as I feel that too often, .NET space has a byzantine amount of layers, so it’s good to see that recent .NET improvements made lightweight approach easier.

Watch it below, and feel free to send your feedback.

You can also find the backing code samples in my repository.

If I had to select the Distributed Systems Song, I’d choose Land of Confusion. This is the world we live in. And these are the hands we’re given. Use them, and let’s start trying. To make it a place worth living in.

Through the years, we didn’t have a handful of options to make it a place worth living in. Yet, recently, we got OpenTelemetry, increasing our likelihood of surviving. In OpenTelemetry, we have traces representing the whole process and spans representing nested processing. Using them, we can get a tree representing our requests/processes flow.

Event Sourcing gives us even more options; we can combine tracing with business facts we store. Typically, we put them into event metadata. By that, we can see correlate technical traces with business information. That’s super powerful if we try to diagnose what went wrong. Observe trends, etc.

I wrote today about combining OpenTelemetry and Event Sourcing using Marten as an example.

Oskar Dudycz - Set up OpenTelemetry with Event Sourcing and Marten

The “get back to desk” is becoming a new industry trend. Recently Amazon CEO wrote a love letter about that approach:

Amazon - Update from Andy Jassy on return to office plans

Yes, I’m snarky here because I don’t like hypocrisy. Such statements are not surprising, as being remote was forced on many companies. They had to adapt. Even those most reluctant. They’re using terms like company culture, collaboration, and team spirit. When we all know is that it’s an Orwellian inversion of meaning:

company culture means that management believes that seeing employees in the office gives them the illusion of control; when they don’t see them, they get lost,
collaboration means too often that they have signed office lease agreements for several years ahead,
team spirit, for some extroverts, means more options to engage with coworkers; for introverts, a nightmare of continuous distractions.

Of course, it’s not that black and white. I agree that constantly remote and asynchronous makes it hard to build real relationships. I faced that myself; I joined Event Store during the pandemic and saw my colleagues live after I left at the DDDEU conference.

Online meetings are not the same. For example, I don’t like chitchatting during online meetings; it makes me angry if people are not going straight to the point; I don’t see that in in-person meetings.

Capacity planning in the office is a hard thing. If you don’t know how many people will show up, then it’s hard to plan how big an office you’d like to rent. Hot-seat mode is also challenging, as there will be days when more people come than you expected.

I was managing remote teams a few years before the pandemic and department head, and I know that’s challenging. You need to change your habits, drop old patterns and think about how to be efficient in different conditions; some of those pieces of advice I put here:

And I’d be okay if companies forcing people to get back to desks would be frank with their motivations. It’d also be great if they said what didn’t work for them and why. But instead, they’re writing those love letters painting the grass green.

Read also a great article by Mark Seeman that I’m fully signing on:

Mark Seemann - A thought on workplace flexibility and asynchrony

So software design and architecture is a human construction. Embracing that and aligning our approach to the teams and conditions we have is essential. We need to be frank with ourselves to build the right synergy. Instead of doing an easy but false choices organisations should do a step back and think on the stuff explained here:

Are you a Postgres fan like me? Or maybe you’re considering joining the club? I have a nice rabbit hole for you. Recordings of the last year's PGConf:

United States PostgreSQL Association - PGConf NYC 2022

Honeypot creates a decent documentary about our industry. Showing the background and history of how the popular tooling was built. This time they explained how React was created and how it succeeded in breaking the monopoly of AngularJs and set its reign:

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 the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.

Architecture

Databases

United States PostgreSQL Association - PGConf NYC 2022

DevOps

.NET

Node.js

Immutable - Immutable collections for JavaScript

TypeScript

TypeScript Deep Dive - Nominal Typing

Coding Life

Industry

Thank you for reading Architecture Weekly. If you like this post, share it with your friends!

Architecture Weekly