fn(args, deps) and Composition — Know When to Nest the Dolls

Just because two pieces of code look the same does not mean they are the same.

The most common architecture mistake is not too little abstraction. It is too much, too early. You see duplication, you extract a shared module, and six months later that module is a monster held together by special cases and boolean flags.

Dan Abramov gave a talk about this called The Wet Codebase. The core argument: the wrong abstraction is far more expensive than duplication. Once an abstraction exists, it creates inertia. Nobody wants to be the person who suggests copy-paste.

fn(args, deps) changes this calculus. It makes abstractions cheap to create, cheap to test, and cheap to undo.

When a function's deps grow too large, that can be a signal that some responsibility has stabilized into its own function — and that new function itself follows fn(args, deps). (This is basically SRP pressure showing up in your signature; see the SOLID post for that framing.)

Russian dolls. Each layer independently testable. Each layer reversible.