Architecture Weekly #88 - 15th August 2022
Welcome to the new week!
I’ll start with an invitation to this week’s webinars that I’ll be running.
The first one is Pragmatic Event Sourcing in .NET With Marten. I’ll show in practice that Event Sourcing is (contrary to common belief) highly practical and not as complicated as it’s pictured. You’ll also see why Marten can give you a boost with its pragmatic attitude. The webinar will be run thanks as part of the JetBrains webinars on Tuesday 16th at 2 PM UTC. More details here: https://blog.jetbrains.com/dotnet/2022/07/15/webinar-pragmatic-event-sourcing-in-net-with-marten/.
The second one is Implementing Distributed Processes. It’ll be run for the Event Sourcerers Community. What’s it and how to join it? By becoming the paid Architecture Weekly subscriber or my GitHub sponsor. Feel invited. Ok, but what’ll be the exact topic? Some time ago, I added Java samples of Distributed Processing (See more in Event-driven distributed processes by example). During the webinar, I'd like to port them to C# and, while doing, explain the nuances of the implementation and design decisions. It will be a chance to have more interactions and discussions.
Most of our design struggles are related to trying to create a perfect solution. It'll be perfect because it can be set in stone once we develop it. That's rarely possible. As we strive to do one and done, we're afraid to fail and fight ourselves. In my last article: Why are we afraid of our decisions? I wrote more about the origins and potential solutions. It’s easy to say, “just keep the right balance!” or “just write simple code!”.
Jeremy D. Miller wrote in Putting SOLID into Perspective a thorough take on what “simple code” means to him. SOLID and Clean Code principles put you in a love & hate relationship. Nowadays, many people (including me) are ranting about SOLID. Jeremy took a breath and wrote a nuanced explanation.
I was taught (at university, work) that I should strive to create an architecture that’s easy to maintain and evolve. That’s also easier to say than follow. The more prescriptive would be to say that we should build solutions that are replaceable or even easy to remove. Such an attitude focuses on composability and building solutions from smaller blocks. We’re also not focused on something that should last and be set in stone. We embrace the change and accept that our design should evolve. Smaller elements are also easier to understand and reduce the cognitive load. What’s that? Check the InfoQ panel: the True Bottleneck in Software Engineering - Cognitive Load. Moderated by Jessica Kerr and run with
Jean Yang, Manuel Pais, Arty Starr provide great insight into why reducing it is an essential part of the efficient development process.
Proper boundaries set good foundations for the right decisions. We can break down our complex problems into smaller departments. They can be focused on a certain business area or workflow, be easier to understand and reduce the number of modules we need to touch to provide a change. Check more in:
Maciej "MJ" Jedrzejewski - Story 2: Call it microservices…or distributed modules?
Nick Tune, Kacper Gunia - Independent Value Streams with Domain-Driven Design
The final aspect that’s too often forgotten is the human-to-human relationship. We didn’t become developers to talk to humans, aye? It’s the contrary. You know IT means Information Technology. Information can be gathered, but usually, it’s done for a reason. And the reason is: to be able to use it. Information needs to flow between humans also, through our colleagues. In my project, I always emphasise the value of proper information flow. Damian Płaza in Organization-Driven Design wrote an intriguing take on looking at our design as a human organisation.
The jazzy way to deal with that in the Agile world are: Pair and Mob Programming. They facilitate collaboration and enhance mutual understanding. They’re extreme (hey, they come from Extreme Programming!), but they work. I wrote my concerns in Agile vs Introverts, but I cannot deny that if they’re done correctly, with empathy and not forcing anyone, then they’re highly effective. If you want to try it or improve your experience, then check those thorough, balanced takes:
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.
Architecture
InfoQ - Panel: the True Bottleneck in Software Engineering - Cognitive Load
Maciej "MJ" Jedrzejewski - Story 2: Call it microservices…or distributed modules?
Nick Tune, Kacper Gunia - Independent Value Streams with Domain-Driven Design
Distributed Systems
Databases
DevOps
Colima - container runtimes on macOS (and Linux) with minimal setup
InfoQ - Are Recursive Serverless Functions the Biggest Billing Risk on the Cloud?
Frontend
Functional Programming
Go
Java
.NET
Coding Life
Dennis Doomen - How I keep my Git source control history clean
Bret Cameron - Why the Dunning-Kruger Curves You’ve Seen Are Wrong
Security
ArsTechnica - North Korea-backed hackers have a clever way to read your Gmail
Twilio - Incident Report: Employee and Customer Account Compromise