Ways of working · 3 min
The abstractions I like leave less to think about
Complexity does not disappear. A clear boundary keeps it from becoming everybody’s problem.
Start by naming the problem
I trust a module more when its responsibility fits into a sentence. What does it handle? What does it accept? What is explicitly outside its job? Clear names, boundaries, and failure modes tend to make the implementation easier to understand too.
An abstraction that requires learning an entire framework before doing one small thing may have moved the complexity rather than contained it. More layers do not automatically mean less to remember.
A model should remove guesswork
Consider a field in a data table. Its identifier and display name are different things. The name can change; references should not break with it. Making that distinction explicit is more reliable than asking everyone to remember not to use names as keys.
This is what draws me to domain modeling: turning an informal agreement into something the system can express. The point is not to look rigorous. It is to leave less guesswork for the next person who changes it.
type Field = {
id: string; // stable identity
name: string; // editable label
kind: 'text' | 'number';
};An interface is a boundary too
A useful interface should not pour every internal state into the user’s lap. It should explain what is possible, what an action will do, and how to continue when something goes wrong. Caches, queues, and transactions do not necessarily need to become three new concepts in the UI.
Hiding implementation is not hiding consequences. What a deletion affects, whether a change was saved, and whether it can be undone still need to be clear. Less machinery to understand should not mean less control.
Give change one place to enter
A boundary is also valuable when it keeps a change local. Storage can evolve without changing record identities. A page can be redesigned without duplicating domain rules.
Not every small program needs an elaborate architecture. I would rather start with a real problem, then find the boundary worth protecting, than design for every imaginable future.
Return to the person using it
My final question is simple: how much extra information does someone new to this part of the system need to remember before safely making one small change? If the answer has not become smaller, even a beautiful structure deserves another look.