- code to an interface not an implementation
- segregate interfaces, don’t overload them with responsibilities
You could have a really skinny interface (one method call only):
class TaxLogic {
data = iDatabase.loadOneDatabaseRow(id);
process(data);
}
interface IDatabase {
loadOneDatabaseRow(id);
}
class PostgresDb implements IDatabase {
loadOneDatabaseRow(id) {...}
}
But this violates ports and adapters because the logic is on the outside and the database is on the inside.It's not wrong but it's also nothing new - it's about as novel as object oriented programming or DRY.
What it doesn't go into is the fact you don't know if it's a shitty overcomplicated interface or not for about a decade at least, until everyone has built their universe on top of it.
What we have in the article is survivor bias. Things that are exemplars rather than the status quo and that's a good thing. But even considering what it explains, we will still blow our toes off 9 out of 10 times.
This is tight coupling.
What does screw you is things that are hard to reason about and you don't know if you can reason about them until many years have passed or you've tried to replace either side of the abstraction.
This is tight coupling.
Come to think of it: that also applies to physical infrastructure: building codes & materials, road networks, AC power grids, gas stations + associated infrastructure to supply those, telecom networks, etc etc. Anything deployed at scale tends to evolve slowly.
Come to think of it: ... [biology]
I think the 'waist' in this case is just 'interface', in the general sense - i.e. where two pieces of software meet.
You make the {N-waist-M} composition problem easier because not much detail can leak from N to M and vice-versa. N and M only need to know about e.g. JSON to compile, not each other.
I'd consider a slightly fatter waist to be something like LLVM. My language is wide and complicated, and all the various assembler outputs for different architectures are also wide and complicated, and the idea of LLVM is to bridge the two, but it still feels like it would be a pain to couple my language to LLVM (JSON is narrower than LLVM)