Modularity Is Not an End in Itself

It is surprisingly easy to talk about software architecture in the abstract. Layers, patterns, dependencies, and rules can quickly start to sound more important than the product they are supposed to serve.

For me, the more useful question is simpler: how hard is the next meaningful change?

If a small product decision suddenly touches five unrelated parts of a system, that is usually a signal. If one area can evolve without destabilising everything around it, the architecture is probably closer to doing its actual job.

Modularity creates room to move

Modularity does not mean creating as many folders, packages, or interfaces as possible. A bad boundary does not become better just because it has its own name.

Good modules keep things together that change for the same reason. At the same time, they keep apart details that should be able to evolve independently.

The goal is room to move. A new idea should not fail because earlier decisions have been scattered throughout the codebase.

Clean architecture as a tool

I do not see "clean architecture" as a rulebook that has to be implemented the same way in every project. The underlying ideas are valuable: design dependencies deliberately, keep domain logic separate from infrastructure, and keep technical details replaceable where replacement is realistically useful.

But every abstraction has a cost. It has to be understood, maintained, and justified.

The cleanest architecture is therefore not the one with the most layers. It is the one whose boundaries fit the actual product.

Frontend and backend are one system

Modern web applications make it tempting to treat frontend and backend as completely separate worlds. For users, that boundary does not exist.

A data model affects the interface. Loading behaviour affects interaction. An API decision can determine how naturally a state can be represented in the UI.

For me, clean architecture also means designing those transitions consciously.

Architecture is a promise to the future

You cannot know every future requirement. Trying to anticipate all of them often produces systems that are abstract long before they need to be.

What you can do is make today's decisions understandable tomorrow.

That is the value of modularity. Not perfection. Not maximum flexibility. The ability to keep developing a product without becoming afraid of your own code every time a good new idea appears.