Jan 23

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:

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

DevOps

Databases

.NET

Coding Life

Management

Product Design

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

Industry

Security

Trivia

Nick Cave - Chat GPT. What do you think?

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