Frontend Architecture

Architecture = Responsibility Management

Systems Start Simple↓Pressure Appears↓Responsibilities Emerge↓Architecture Evolves↓Scale Introduces Constraints↓Trade-offs Become Unavoidable

Before Architecture

Most applications do not start with an architecture.

They start with a file.

Then the file grows.

Responsibilities begin to mix.

At some point, the team needs a way to organize change.

That is when structures like layers, feature folders, hexagonal architecture, clean architecture, or microfrontends start to appear.

Architecture is not just organizing folders. It is deciding where responsibilities should live and how they should depend on each other.

Different architectures propose different boundaries.

Layered Architecture

UI
↓
Services
↓
Data Access
↓
API

Feature-Based Architecture

features/
  auth/
  checkout/
  products/
  orders/

Hexagonal Architecture

UI
↓
Ports
↓
Domain
↓
Adapters

Microfrontend Architecture

Catalog Team  → catalog app
Checkout Team → checkout app
Payments Team → payments app

The goal is always the same: manage responsibilities under pressure.

Chapter 0 — Why Architecture Appears

Explains why architecture exists and how it emerges from pressure applied to simple systems.

Systems Start Simple

  • Most systems begin as a single feature.
  • UI, state, API calls, and business rules often live together.
  • Everything works.
  • At this stage, architecture is unnecessary.

Pressure Appears

  • More users.
  • More features.
  • More engineers.
  • More business rules.
  • The system still works, but it becomes harder to evolve.

Responsibilities Collide

  • The same code starts rendering UI, managing state, calling APIs, validating rules, and handling errors.
  • Large files appear.
  • Duplication increases.
  • Testing becomes harder.
  • Changing code becomes risky.

Boundaries Emerge

  • Teams begin separating responsibilities.
  • UI becomes separate from state.
  • Business logic moves away from components.
  • Data access becomes isolated.
  • Architecture emerges because the system demands it.

Mental Model

  • Pressure creates responsibility.
  • Responsibility requires boundaries.
  • Boundaries create architecture.

Why This Matters

  • Most architectural discussions start with solutions.
  • This project starts with pressure.
  • Understanding why a boundary appears is more important than memorizing a pattern.

Key Takeaway

Architecture is not the process of adding layers. Architecture is the process of managing responsibilities under pressure.

Final Reflection

Systems start simple.

Pressure appears.

Responsibilities emerge.

Architecture evolves.

Scale introduces constraints.

Trade-offs become unavoidable.


Architecture is not the process of adding layers.

Architecture is the process of managing responsibilities under pressure.

Every abstraction exists because something became difficult.

Every solution introduces a new trade-off.

Architecture evolves because systems evolve.