Architecture Weekly #128 - 22th May 2023

May 22, 2023

Welcome to the new week!

It’s an anniversary release of the Architecture Weekly 10000000! How quickly did it go? Woohoo!

Usually, one of the main drivers for Event Sourcing is the audit log capability. Indeed event stores are append-only logs, theoretically, we're getting that for free. Yet, I'm usually not putting it as the front reason, and there are a few reasons for that.

I tried to cover them in my latest article, as I prefer people jump on the Event Sourcing bandwagon because it's helpful for them rather than being blind by the hype and then failing.

Is the audit log a proper architecture driver for Event Sourcing?

As architects, we should always try to challenge the status quo. Of course, not just for disagreeing, but to ensure that our common practices have a ground basis or are rituals. Michale Feathers, in his classic article, wrote about using mocks:

My point is that we can't look at testing mechanistically. Unit testing does not improve quality just by catching errors at the unit level. And, integration testing does not improve quality just by catching errors at the integration level.

Discussions Unit vs Integration etc. are usually meaningless if they don’t involve the context and the feature we’d like to test. Read more in:

Michael Feathers - The Flawed Theory Behind Unit Testing

Have a look also at the recent Rebecca Wirf-Brock article showing the testing and development process from multiple angles. It neatly explains that testing is not only about quality assurance.

Rebecca Wirf-Brock - Getting out of your ruts

I think that you should already know that I’m not fond of craftsmanship, clean code and other Robert C. Martin concepts. There are many reasons for that, I presented some in What onion has to do with Clean Code?. Criticism is good as long as it’s based on facts and is constructive. That’s what Kevlin Henney did in his talk. Watch more in:

Kevlin Henney - The SOLID Design Principles Deconstructed

Some may say that such stuff is about tactics, and strategy is important. My take is that all are important; the big things are built from the small ones. A great strategy won’t work with the wrong execution. Also, projects are failing from the wrong vision and those annoying papercuts that are killing projects every day.

Yet, from my experience shaping the right product direction is one of the essential things. Of course, we’re usually building software to earn money, but if earning money is our primary goal, we don’t have a differentiator, as all the others also want that.

To be a good product manager is not easy; you need to acquire multiple skills: design, management, empathy, collaboration, etc.

Check those two links to read more about product development:

Have a read also about the classic work on how to acquire the skills from Dreyfus & Dreyfus. This is the groundwork in this area, surprisingly not much has changed from the release of it:

S. E. Dreyfus, H. L. Dreyfus - A five-stage model of the mental activities involved in directed skill acquisition

Architecture

DevOps

Elif Samedin, Andrei Buzoianu - Terraform check{} Block - define assertions based on data source values to verify the state of the infrastructure

Architecture Weekly

Architecture Weekly #128 - 22th May 2023

Architecture

DevOps

Testing

Frontend

AI

Azure

Java

.NET

Python

Management

Product Design

Security

Discussion about this post