Modeling.
Not docker, kubernetes, service mesh, so-called “CI servers,” etc. It isn’t tooling holding you back.
In the work I’ve done over the years helping teams achieve autonomy in their code bases, modeling the system in a new way is what trips everyone up.
Simply put, just because two pieces of data share a common identifier does not mean they’re part of the same thing.
Missing that point is the essence of a monolith, whether or not the pieces of your system run on more than one computer. Mere distribution does not microservices make.
MVC (model-view-controller) framework orthodoxy guides developers towards first making database tables. We know we’re going to have users, so let’s make a table that holds everything related to users.
What behavior in your system does not care about who is doing the behavior? I like the way Udi Dahan puts it, to avoid thinking in terms of nouns and verbs. In this type of modeling, every time you have a noun doing a verb to another noun, you’ve created coupling on either side of that verb. Coupling, at least the wrong kind of coupling, is why your teams take a year and a half to ship 6-week features.
Instead, start with behavior Data is a by-product of behavior. It’s the behaviors that can give you cohesion.
Why is the Eventide Project’s funds-transfer-component able to leverage the account-componentto enact funds transfers without any changes being made to account-component? Because the latter is the cohesive behavior of maintaining an account balance. The temptation is to view the account as a noun, a thing that holds money. So any operation that involves moving money would go on an account.
There be dragons. How many different operations in a bank involve money? Somewhere close to “all of them,” I suspect. That would mean that this one noun would slowly accumulate every bit of functionality in the bank. Have fun changing that! Especially if you weren’t producing tests so that you could “move fast.”
Udi Dahan goes on to share a useful strategy to avoiding this kind of monolithic design—focus on the individual data attributes. Which of them need transactional consistency with each other? A funds transfer doesn’t actually need transactional consistency with the accounts’ balances. Your users’ timezones and storage quotas probably don’t need transactional consistency with each other.
Go have a look at some of your widest tables. Look at each column. Do you have any operations that need every single one of those columns to be in transactional consistency with each other?
I guess this wasn’t a technical impediment after all. It is we meat sacks all the way down.
