Discover more from Architecture Weekly

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

Over 3,000 subscribers

Architecture Weekly #76 - 23rd May 2022

Oskar Dudycz

May 23, 2022

Welcome to the new week!

As the years go by, I conclude that the simpler, the more boring, the better. To software architecture, that rule also applies. Each abstraction has its costs; the more layers and complex constructions, the riskier and fragile it is. I’m not a huge fan of clean coding and clean architecture. I believe that’s an obsolete approach that (maybe) was good when it was intended, but I also doubt it. It’s overly complicated and explained as one way to rule them all.

Of course, telling someone “just write simple code” is not actionable. Simple code is not simple to write. It requires several iterations and putting thoughts and discussions into it. It’s a paradox that it’s much easier to write complex code. Why? It’s easier to add another layer or stack a new code structure. Decoupling everything (e.g. with interfaces) also helps, as we do not immediately see the results of our actions. Yet, we’ll pay for all of that, but not now, later.

My hot take is that if we’re discussing the separation of concerns, our concerns should be business features, not technical split. Or both, but for sure, the technical one should not be our end goal.

We're sometimes too focused on the technical aspect because we're trying to tame what we can control. Many organisations often have a clear split between "business and devs". If you're in that position, then you won't ever see a client; you might not be even able to discuss requirements, so devs are trying to control what they can: code structure. And that becomes their (Chesterton's) fence and the main focus to do it right.

Of course, some developers just don't care about the business. They see programming as a riddle-solving or like to play with tech.

In my last article, I wrote my take on What onion has to do with Clean Code?

For more, check also:

Microservices and lessons learned from them are always a hot topic. They already passed the buzzword phase, and there are some good insights both on how to do them right and bad. Check:

I’m thinking about learning some crazier lower-level language like Rust or Go. For the latter, the decent starting point looks like this ebook:

Chris Noring - Go, from the beginning

I’m not a massive fan of the “Web3”, but this sounds like an intriguing thing to keep an eye on:

Check also more links below!

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). This is a great space for knowledge sharing. Don’t wait to be a part of it! We had our first webinar recently about migrating from CRUD to Event Sourcing. If you join, you’ll also get access to the recording.

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.