Olivier Lowe

This technical article is available in English.

FRONTEND ARCHITECTURE · ANGULAR · NAVIGATION

Navigation Is Not the Business

The URL knew where the customer was. That did not make the URL the owner of the workflow.

NovaTrade already had a checkout workflow with two meaningful positions:

Edit
  ↓
Review

At first, that position existed only inside local workflow state.

The application knew whether the customer was editing or reviewing an Order.

The browser did not.

Review Acquired Navigation Meaning

Once the customer entered Review, the browser location began to represent that position too.

Edit
  ↓
Review
  ↓
/checkout/review

Returning explicitly to Edit could similarly record:

/checkout/edit

Nothing else needed to move into the URL.

The checkout data, placement progress, placement failures, and Order business rules still had their existing owners.

The URL had earned one responsibility: representing where the customer was in the checkout.

Then the Browser Navigated Too

Writing the location was only the first half of the problem.

Once browser history contained the transition from Edit to Review, the customer could press Back.

That action did not call NovaTrade's own workflow control.

The browser moved through its history independently.

browser location
→ Edit

local workflow state
→ Review

For the first time, NovaTrade had two representations of the customer's position, and they could disagree.

Navigation Had to Restore the Visible Position

If the browser location genuinely represented checkout position, browser navigation could not merely decorate the workflow.

Back and Forward had to restore the corresponding visible state.

browser Back
→ restore Edit

browser Forward
→ restore Review

Navigation and workflow position could no longer evolve independently while both claimed to describe where the customer was.

What About the Initial URL?

Back and Forward proved restoration after the application had already started.

One case remained.

What happens when NovaTrade starts while the browser is already at:

/checkout/review

No Review button has been clicked in the current component instance.

No local Edit-to-Review transition has occurred.

The browser already describes the position before the workflow begins.

So initialization needed to interpret that location too.

initial /checkout/review
        ↓
restore Review

The same location-to-step mapping could now handle both initialization and later browser history changes.

The URL Still Did Not Own the Workflow

At this point it would have been easy to say that the checkout should simply live in the URL.

The implementation did not support that conclusion.

Navigation

Where is the customer?

Workflow

What can the customer do here?

Domain

What does the Order allow?

Those responsibilities participate in the same user journey.

They answer different questions.

navigation state
≠
workflow state
≠
business state

A URL Is Not a General-Purpose State Container

Review belonged in the browser location because checkout position had acquired navigation semantics.

That did not imply that every piece of checkout state belonged there.

The URL could represent:

  • the current checkout position.

It did not therefore own:

  • checkout email;
  • delivery information;
  • placement progress;
  • placement errors;
  • Order validity;
  • business rules.

Those values have different meanings, lifetimes, and owners.

Stop Where the Requirement Stops

Angular already provided routing capabilities.

That did not mean NovaTrade had earned a larger routing architecture.

The verified requirement remained narrow:

represent checkout position
+
restore checkout position

That did not yet require:

  • separate Edit and Review route components;
  • route guards;
  • resolvers;
  • a navigation service;
  • a route-state abstraction;
  • a larger routing architecture.

Those mechanisms may become responsible later if independently addressable screens, route-level loading, guards, lazy feature boundaries, or richer navigation semantics actually appear.

Their availability alone was not evidence that they were needed.

What the Tests Actually Proved

The navigation work was protected by three different behavioral proofs.

enter Review
→ location becomes /checkout/review

That proved representation.

browser Back
→ Edit becomes visible

That proved synchronization.

initial /checkout/review
→ Review becomes visible

That proved restoration.

Together, they proved more than “the URL changes.”

They proved that browser navigation and the visible checkout describe the same position.

They did not prove that navigation owns the workflow.

They did not prove that the URL owns business state.

The Responsibility Split Stayed Small

Navigation
→ represents and restores position

Checkout workflow
→ coordinates progression and available actions

Order
→ owns business state and rules

The important architectural change was not simply the addition of /checkout/review.

It was recognizing that some frontend state can acquire navigation semantics without therefore becoming workflow state or business state.

The Lesson

Put state where its semantics belong.

Some frontend state belongs in the URL because it represents a navigable, restorable position.

That does not make the Router the owner of the workflow.

POSITION → URL → RESTORE → OWNERSHIP

Where the customer is matters.

So does understanding who owns what happens there.

CONTINUE THE ARCHITECTURE JOURNEY

Navigation should represent position, not absorb responsibility.

This Engineering Note comes from the same business-first architecture approach explored in Frontend Architecture with TypeScript, Angular, and React .

Explore the frontend architecture book