Finally Good Architecture Documentation

State Is the Root of All Evil

Hi,

What distinguishes an application from a (mathematical) function?

A function takes an input x and transforms it into an output. If f(x) = 2 * x, then the result of this function for the input of any x is always the same.

There are no side effects. We call this behavior stateless.

But what does this have to do with the question from the beginning? An application goes beyond this. (Almost) every application must work with state. As soon as we have I/O operations in our system, we inherently have state. And often a method call, with the same input, can yield different results at different times. And this is also unavoidable and is in the nature of the task we want to solve.

Marcus Held

Sliced Onion Architecture

Hi,

A week ago, Oliver Drotbohm published an expanded idea of the Onion Architecture: The Sliced Onion Architecture .

Most software developers are familiar with Hexagonal Architecture and its extension, the Onion Architecture . The idea (simplified): One decouples their business code from infrastructure code using adapters.

This makes it less likely to create the “Big Ball of Mud” .

What do I see in practice?

Most developers have understood that it’s a good idea not to mix business code with infrastructure code.

Marcus Held

Double-Entry Bookkeeping

Hi,

An error in accounting can be costly. Especially in large companies, where there are many transactions, it is easy to overlook one.

And when that happens, I might not even notice it. Perhaps the company is doing much better than the books indicate? Or maybe it’s actually unprofitable?

Merchants in the 13th century recognized the problem. A system had to be found that would make errors less likely. They invented double-entry bookkeeping.

Marcus Held

Microservices are a Big Ball of Mud

Over the past years I attended hundreds of interviews. Many candidates proudly told tales on how they develop their projects with a microservice architecture. Often (I don’t want to say “always”, but from my memory I think it actually is “always”) it does not require many questions to see that they used a rocket launcher to kill a mouse. Microservices are hard. Everyone who experienced the pain of operating such an architecture can relate to it. The complexity kills you at one point or the other. You already had to do multiple refactorings of your architecture - because your domains didn’t work out. I wonder - why is this architecture so appealing to developers? And then I remember why I found them appealing 10 years ago.

Marcus Held