Application Architecture

How an end-to-end application is organized. Layered, Hexagonal, Clean, MVC, MVVM, BFF, Vertical Slice.

Application Architecture patterns define how you structure an entire application: where business logic lives, how data enters and exits, which dependencies are allowed between layers, and how infrastructure details are isolated.

#The Problem

Without a clear architecture, everything ends up in the same place: the UI knows the database, the domain imports the ORM, and a framework change means rewriting the business logic. The application grows as a single unstable stack: pull on one brick and everything collapses. Tests require spinning up Postgres, HTTP, and a full moon. Bugs appear in places unrelated to what you changed.

#The Solution

An application architecture defines explicit boundaries between parts and clear rules about who can call whom. The domain is isolated from details, the UI becomes replaceable, and business tests run in milliseconds without touching infrastructure. The framework is no longer the center: it's just another detail, interchangeable.

#Why they matter more than design patterns

A poorly chosen design pattern can be refactored in an afternoon. A poorly chosen architecture can stay with you for years. It's the implicit contract your team signs about how everything that comes next will be written.

#When to use it

  • The project will live for more than six months with several people touching the code.
  • There are business rules that matter more than the database or the framework.
  • You want to be able to replace the UI, ORM, or message broker without rewriting the domain.
  • You need tests that don't spin up Postgres or HTTP.

#When NOT to apply them seriously

  • For a migration script, a 200-line microservice, or a prototype.
  • Clean Architecture in a trivial CRUD app is more expensive than the problem it solves.
  • Hexagonal without real domain tests is just more folders.

#In this chapter

  • Layered — the classic standard.
  • Hexagonal / Ports & Adapters — the domain at the center, infra at the edges.
  • Clean Architecture — opinionated version of Hexagonal with dependencies directed inwards.
  • MVC / MVVM — UI-centric architectures.
  • Vertical Slice — organize by feature rather than by layer.
  • BFF — a dedicated backend per user experience.
  • Layered (N-Tier) — Organizes the application into layers with unidirectional dependencies: Presentation → Application → Domain → Infrastructure.
  • Clean Architecture — Organizes code into concentric layers where the domain is the center and nothing from the outside touches it.
  • Hexagonal (Ports & Adapters) — The domain defines ports (interfaces); each external actor (DB, UI, MQ) interacts through an adapter.
  • Vertical Slice Architecture — Organizes code by feature instead of by layer: each slice contains Web + App + Domain + Infra components for a specific functionality.
  • MVC — Separates the model (data), view (UI), and controller (input) into independent components.
  • MVVM — View ↔ ViewModel ↔ Model: the ViewModel exposes bindable state and commands.
  • Backend for Frontend (BFF) — A dedicated backend per client type (web, mobile, smart TV) that adapts the model to its needs.