[TeMPOraL]

> That looks awfully close to the micro-service approach as well. The approach can be good, but it still gives me pause.

Microservices aside, GP's statement seems to imply composition is like addition wrt. complexity. Unfortunately, in reality it's multiplication. Complexity multiplies with each moving part. There's hardly a better example of that to what we inherited from "original Unix" - chaining small, focused tools in pipes turns into a write-only mess after around the fourth pipe.

Software complexity isn't simply a divide-and-conquer problem, because we pay a penalty for each individual piece, and each piece of glue that connects it with other pieces. That's the whole reason we rely on abstraction and generalization so much - the ability to take a bunch of "small, self-contained, isolated, well-understood parts", put them in a box, and stick a higher-level name to it. Recursively.

[nine_k]

Yes, composing self-contained parts is mere multiplication: if you have two sequentially connected components with m and n states, the composition has no more than m × n states (in practice much fewer).

But if you have two tightly coupled components which can arbitrarily jump into each other's code, you have (m + n)^2 states.

A four-stage Unix pipe is easy to split and thus analyze and understand, step by step, because each step is reasonably small, and has only one input and one output (presumably). Spaghetti code may be impenetrable, and only work by coincidence.