Welcome to the new week!

On Friday I wrote probably one of the lengthiest articles so far. Funnily enough, I did that by accident.

I wanted to write a short example, but the first introductory paragraph changed into Guide to Projections and Read Models in Event-Driven Architecture.

Projections are transformations of information we get from events into other data. We can look at the past and analyse the data, finding even new business models. Thanks to that, we can get business insights and view data from different perspectives.

To implement projections efficiently and benefit fully from their superpowers, we need to take a lot into consideration.

In article, I showed a foundational building block from a big-picture view. Even though it ended up as a lengthy article, there are still things to expand. I hope this article is a decent starting point for you to know how to deal with them and what to watch for.

• Oskar Dudycz - Guide to Projections and Read Models in Event-Driven Architecture

Don’t miss also Einar W. Høst article about craftsmanship, or its death:

• Einar W. Høst - Death of a Craftsman

I can fully sign on it, as it’s pretty much my story, also. Still, it’s always intriguing how language context changes the meaning.

I titled myself “rzemieślnik” for some time, which in the Polish language means craftsman. Yet here where I live, it’s typically used pejoratively. Rzemieślnik is someone capable of doing what they were told to do, but not someone that would invent something or even design.

I stopped saying about myself like that when I understood that I was saying that as a software developer. Then it’s a much different meaning than what was my intention. It’s much more pompous and less about what’s important. My intention for calling myself “rzemieślnik” was the opposite. To highlight that I’m here just to solve someone else intention, so business case and do it best I can.

So the meaning of craftsman in our industry is more like a medieval mason rather than just a person here to do the job. I still believe we should master our skills and be realistic about what we’re here for. Less bravado, more focus on what’s important, so understanding the case we need to solve. And that we’re just a piece in the whole software delivery process.

Embracing that can be quite a relief.

A good way to do that is to learn modelling and collaboration techniques. If you'd like to start with EventStorming, I recommend Kenny Baas-Schwegler's talk:

• Kenny Baas-Schwegler - Crunching 'real-life stories' with DDD & Event Storming

It’s informative and actionable. I also like putting Event Storming in a broader context together with other tools like Example Mapping. The other combination that helps me zoom in and out is Event Storming + C4 model. It helps to make theories and evaluate them around the technical design and tools composition.

Still, modelling is not only about sticky notes; you can also type it. For that, see a detailed example of the thought process that you can apply using a proper type system together with collaboration with business:

• Damian Płaza - Many faces of DDD Aggregates in F#

If you’re looking for a thorough and well-thought explanation of the various layered architecture concepts, check out those talks:

• Herberto Graça: Making architecture explicit

• Glenn F. Henriksen - Building that glorious monolith. And carving it too.

• Ian Cooper - Implementing the Clean Architecture in .NET Core

As you might know, I’m not a fan of layered architecture. I prefer to cut as many layers as possible. Still, those architectures have their place, and if you work with them, it’s worth understanding how to do it right. To do that, we need to understand their origins, context and assumptions that shaped them.

Uber is a bad example in many cases, but they’re a decent example of how you need to adapt your organisation depending on the product phase you’re into.

They started by not maintaining the old code. No rewrites. They just wrote the new version of the service.

Initially, they were focused on technicalities but then learned Domain-Oriented Architecture. Because they also learned the domain and embraced that they’re not just about technology.

Now they came into the mono repo and remote dev environments. See:

• Uber - Devpod: Improving Developer Productivity at Uber with Remote Development

I’m not sure yet if that’s the correct decision.

I’m trying to say here that we should constantly reevaluate architectural, people and organisation decisions. We should not be trying to build the perfect model. There are no such. We should make mistakes in a controlled way and learn from them. That’s how we’re making progress.

Of course, sometimes it’s better to stand smartly than run blindly, but that’s for another story.

Bored with ChatGPT? Me too, but hey, even Nick Cave wrote about that:

• Nick Cave - Chat GPT. What do you think?

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

• Oskar Dudycz - Guide to Projections and Read Models in Event-Driven Architecture

• Glenn F. Henriksen - Building that glorious monolith. And carving it too.

• Herberto Graça: Making architecture explicit

• Kenny Baas-Schwegler - Crunching 'real-life stories' with DDD & Event Storming

• Virtual Domain-Driven Design - Trying out online EventStorming

• Pat Kua — Organising and Governing Evolutionary Architectures (Fitness Functions)

DevOps

• OpenGitOps - a set of open-source standards, best practices, and community-focused education to help organizations adopt a structured, standardized approach to implementing GitOps

• Arek Borucki - Deploying the MongoDB Enterprise Kubernetes Operator on Google Cloud

Databases

• Paul McJones - The 1995 SQL Reunion: People, Projects, and Politics

• Francesco Tisiot - How to JSON in PostgreSQL

AWS

• AWS - Generate Excel workbooks from Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL

Azure

• Microsoft - The Azure FinOps Guide

Java

• Gavin Ray - Building a PostgreSQL Wire Protocol Server using Vanilla, Modern Java 21

.NET

• Jeremy D. Miller - Wolverine meets EF Core and Sql Server

• Damian Płaza - Many faces of DDD Aggregates in F#

• Ian Cooper - Implementing the Clean Architecture in .NET Core

• Damien Bowden - Implementing secure Microsoft Graph application clients in ASP.NET Core

Coding Life

• Einar W. Høst - Death of a Craftsman

• Mark Seemann - In the long run

• Steve Wozniak - The early days

Management

• Uber - Devpod: Improving Developer Productivity at Uber with Remote Development

• Jim Little - Change Your Organization (For Peons)

• Ted Neward - Where does DevRel fit on an org chart?

Product Design

• Lars Kamp - Messaging, positioning and storytelling - how to get it right for your start-up

Industry

• Frank Landymore - CNET Is Quietly Publishing Entire Articles Generated By AI

• John Voorhees - Twitter Intentionally Ends Third-Party App Developer Access to Its APIs

Security

• Financial Times - Chinese researchers claim to find way to break encryption using quantum computers

• Tim Bray - Private and Public Mastodon

• Rob Chahin - The SSO Wall of Shame

Trivia

• Nick Cave - Chat GPT. What do you think?