Strategic Frontend Design

Architecture does not begin with deciding which store owns which state or which class calls which mapper.

Some of the most important decisions happen much earlier.

Where should a domain boundary run? Which parts of a system should evolve together, and which should remain as independent as possible? Which team owns which responsibility? Where does coupling emerge? And which decision looks pragmatic today but becomes expensive three years from now?

That is where Strategic Frontend Design begins.

Why “strategic”?

The term is deliberately inspired by strategic design in Domain-Driven Design.

At that level, DDD is not primarily concerned with entities, value objects, or repositories. It looks at the larger shape of a system: domain boundaries, responsibilities, relationships between contexts, and the question of which parts should be treated as belonging together in the first place.

Frontend systems face very similar questions.

Should a large frontend remain one application, or are there good reasons to split it into independently developed parts? Where does one domain area end and another begin? Does a shared service genuinely belong to everyone, or has it simply become the place where nobody owns the responsibility anymore? Do two teams really need the same model, or is that shared model already creating unwanted coupling?

These decisions sit above individual components, stores, or libraries. They define the space in which implementation decisions later have to work.

Strategic Frontend Design is therefore about shaping the system before deciding how that shape is implemented in code.

Boundaries are rarely only technical

Many architecture problems first appear to be technical.

A module becomes too large. Two teams keep changing the same files. A shared model accumulates more and more exceptions. Deployments become harder to coordinate. A shared package slowly learns about half the application.

But the root cause does not necessarily live in the code.

The domain boundary may be unclear. Two teams may share a responsibility that should have been separated. An organizational structure may have been reflected in the software even though the domain does not follow the same lines. Or an integration model may have been convenient at the beginning and gradually become more expensive to coordinate.

That is why strategic architecture cannot be understood by looking only at folders, classes, or repositories.

It connects domain concerns, technology, organization, and economics.

A boundary can be technically elegant and still be awkward for the teams that have to work with it. It can increase team autonomy while making infrastructure more expensive. It can simplify deployments in one place while introducing new integration problems somewhere else.

Strategic architecture is therefore often less about finding a perfect structure and more about making the consequences of a structural decision visible early enough.

Two perspectives on the same question

The two series in this area approach boundaries from very different directions.

Big Ball of Mud

A Big Ball of Mud rarely exists because a team deliberately decided to create as much coupling as possible.

It usually emerges gradually.

Responsibilities become shared, boundaries grow more permeable, temporary shortcuts become permanent, and knowledge spreads across more and more parts of the system. Each individual decision may have been understandable in its original context. Taken together, however, they can create a system in which even small changes require increasing amounts of coordination.

The series therefore looks beyond code. It also examines the organizational and economic conditions under which these systems emerge, and why separating them again later can become so difficult.

Microfrontends

Microfrontends start from the opposite direction.

Here, separation is intentional.

Teams are expected to work more independently, parts of an application may be developed separately, and in some cases they can even be deployed independently.

But splitting the application does not make the boundary question disappear. It makes that question more important.

A microfrontend boundary can enable real autonomy. It can also take coupling that already exists and distribute it across multiple applications, repositories, deployments, and teams.

So the interesting question is not whether microfrontends are modern or whether they are generally a good idea.

The more useful question is:

Which boundary are we trying to protect, and what are we willing to pay for that independence?

Strategy creates the space for tactics

Strategic and tactical design are not competing architecture approaches.

They answer different questions.

Strategic Frontend Design deals with system boundaries, responsibilities, and relationships between larger parts of a frontend landscape.

Tactical Frontend Design starts one level below that. Once a boundary makes sense conceptually, the next question is how that boundary becomes visible in concrete code.

Strategic design asks:

Where should the boundary be?

Tactical design asks:

How should that boundary take shape in code?

Both matter.

A perfectly designed store cannot compensate for the wrong system boundary. But a sensible domain boundary will not help much either if every responsibility inside it ends up everywhere.

No architecture theatre

Strategic architecture can easily sound larger than it needs to be.

Not every frontend needs multiple deployments, platform teams, or sophisticated integration models. Sometimes a well-structured monolith is exactly the right solution.

The goal is not to produce as much architecture as possible.

The important part is to make conscious decisions about which things should evolve together, which need to remain independent, and which forms of coupling the system can afford over time.

That is what this area is about.

Not bigger diagrams, but decisions whose consequences often outlive the code that originally implemented them.