Discover more from Architecture Weekly

Weekly Software Architecture resources to boost your knowledge and developer skills.

Over 4,000 subscribers

Architecture Weekly #93 - 19th September 2022

Oskar Dudycz

Sep 19, 2022

Welcome to the new week!

Event Sourcing is pictured as a hyped but impractical pattern. The reality is the opposite. It can help to capture, model and implement your business process efficiently. One of the reasons is that there are not enough practical resources to get you started. I know how hard it may be, as I've been there and was banging my head into the wall.

Yet, I survived and got my lessons. You can benefit from my battle scars and have a smoother path. I prepared highly practical and hands-on workshops to get you started.

Together with Domain-Driven Design Europe, I'll be running an online open one in November. Check the details below.

Event Sourcing: Practical Introduction

Feel invited!

If you have questions or concerns, feel free to ask!

We work in an industry that’s full of passionate people. Doing what you like and getting paid for it is a privilege and a curse. We’re vulnerable to workaholism and burnout. I hear many stories from my colleagues about not wanting to quit their current job because they care too much about the team, rare tech stack, or money, even though they’re constantly tired. Leaving a toxic job is not quitting. It’s self-defence. Many times I wasn’t great at caring about my mental safety. You can do better. Check more in my last article:

It doesn't have to be toxic at work

To be a good technical leader and architect, it’s crucial to understand that Software Architecture is not only about tech. It’s a socio-technical construction. Most of the project failures I’ve seen were not about the wrong technical design but the bad people management and product prioritisation. I’m happy that this aspect is more and more investigated. We’re getting better “tools” to understand the correlation. Check more in the great talk by Susanne Keiser:

Susanne Kaiser - Architecture for Flow with Wardley Mapping, DDD, and Team Topologies

Dave Thomas said: “Big design up front is dumb, but doing no design up front is even dumber”, and I fully agree with that. I said that several times, but having proper documentation is foundational for building the right company culture. It enhances transparency in decision-making and reduces cognitive load. Yet, it’s not easy without the proper tooling. Check some tooling that can help you:

I’m sceptical of cryptocurrencies and the tooling around them. That’s also why they’re not showing up too often. My personal take is that this tech stack will be much more valuable for stuff like notarial acts and other confirmations rather than currencies. Currently, the money mirage is used by scammers, but it’s undeniable that some algorithms and tooling can be used for a wider purpose. The old model of mining is also terrible for our environment; I’m happy that the community pressure forces decision-makers to reduce this damage. Still, even from the purely technical perspective, it’s worth checking Ethereum merge, and how they changed their core tooling and algorithm. I think that this can be one of the biggest software upgrades in software history. Check more:

PCMag - ‘No One Is Profitable’: GPU Mining Faces Dark Days After Ethereum Merge

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.