Debugging
For you architects reading this, you should get involved in debugging and production outages…
I know, I know. Your ivory tower is super comfortable with the reclining chairs and central heating. But the insight you can gain from getting down into the engine room is priceless.
One of the easiest ways to understand the constraints of a system is at the exact point these fringes are being pushed. Production outages and issues tell you that.
In this article, Gregor shows that
A fantastic way in which systems tell us that we are wrong is debugging (including trouble-shooting operational issues). Debugging happens when reality deviates from what you intended it to be, i.e., you were wrong in some way. The task now is to figure out where you were wrong. That means the happiest moment of debugging is when you find out where you were wrong:
Gregor Hohpe, Debugging Architects
Debugging gives you priceless insight. Which you can take back up to ivory tower and use to improve that component of a system, but also the wider system.
One of your jobs as a modern software architect is to think about the wider system, the architecture of it’s entirety and the interplay between the smaller components.
Understanding where one component went wrong gives you a valuable lesson. You can take that lesson to other components to stop them making the same mistake.
Cleaning
Don’t worry, this newsletter hasn’t magically transformed into good housekeeping.
Let’s talk about clean architecture.
I’ve seen various ‘hot takes’ and commentary on social media recently arguing that clean architecture is overkill.
It adds a lot of unnecessary boilerplate and formality etc etc etc…
This post from the Software Alchemy blog gives you an introduction and also shows how clean architecture fits into the wider ideas of domain driven design.
The ‘hot takes’ are interesting though. And I think there is a middle ground to be found here.
One thing I’ve learned over the years is that simple is good. So if you’re building a simple system (I’m looking at all the CRUD API’s out there), DDD and clean architecture are overkill. A simple repository pattern with some API endpoints will work perfectly.
But, and it’s a big but. If you’re working on a core domain that is complex and evolves quickly, putting time into the structure of your code upfront will save you time in the long run.
Initially, it may seem more complex. But as your system develops, the simplicity becomes clear.
As everything in our industry comes back to, it ALWAYS depends. The best heuristic to use? Simple is good, so keep it simple. Adopt the complexity when the business and system requirements need it.
It’s part of the reason I love AWS Lambda, simple.
Testing
Event Driven Architecture (EDA), one of the most common patterns in modern software development.
So common, I’m going to be talking about it at NDC London 2024.
The benefits of adopting EDA are SEEMINGLY infinite. Loose coupling, asynchronous communication, teams operating independently, extensibility built in.
And then you need to test it…
Testing event driven systems is hard. Mostly because of their asynchronous nature.
If you’re testing a synchronous process, you Act, and then once the response comes back you Assert.
With an event driven system, you Act and then have know way of knowing when is the right time to Assert. Of course, you can assert that your original request completes successfully. But how do you ensure that the asynchronous process you expect to run in the future actually happens?
This article from Steve Morland tackles these testing challenges through a deep dive into how his company actually worked through this problem.
It’s AWS specific, but the process used could be applied anywhere.