Hi,

An old developer joke:

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. – Leon Bambrick

Or another version:

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery – Mathias Verraes

And there are many more:

There are so many variations on the “there are only two hard problems in computer programming…” joke that I’m starting to suspect that programming isn’t actually very easy. – Nat Pryce

(Credit to Martin Fowler for this list)

Today, I want to write about a topic that is not only difficult but also damn expensive if you get it wrong.

Module Boundaries

The question is as old as computer science itself. From the beginning, it was understood that it is sensible to abstract and group cohesive functions. The hype around DDD and Microservices has further fueled the topic. Especially when you outsource the modules into separate services, the decision becomes particularly expensive. A sure cause of Accidental Complexity .

So the question arises: How should I cut my modules?

There are entire books on this question. Trying to answer it in this newsletter would be presumptuous.

However, I have seen a nice visualization by Kent Beck that helps me reflect on the question.

Imagine the red area corresponds to a feature/component/data structure. It fits for everything.

I can use the visualization on all levels:

• Is my service properly divided?
• Is my class properly divided?
• Is my function properly divided?
• Is my entity properly divided?

Interestingly, I see most mistakes today in the middle. Most structures are too small.

The hype around Microservices leads to many too-small services in the architecture.

Too strict normalization in the database distributes the data across too many tables.

Too strict interpretation of the Single Responsibility Principle leads developers to write too many classes for one function.

Less often, I see things being too big. But they exist in abundance as well. The notorious spaghetti monolith. The art is to get it just right. But I rarely achieve that on the first try. You don’t need to aim for that either. Don’t tend toward either extreme.

It is like everything in life: Tend towards a healthy middle.

Rule the Backend,

~ Marcus