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.
  • Onion — concentric layers with the domain model at the center.
  • Clean Architecture — opinionated version with use cases in the lead and dependencies directed inwards.
  • Comparison — how Layered, Hexagonal, Onion, Clean and Vertical Slice are alike and different.
  • MVC / MVVM — UI-centric architectures.
  • Vertical Slice — organize by feature rather than by layer.
  • BFF — a dedicated backend per user experience.

#How to choose: key questions

There is no "best" architecture. Answer this before choosing:

  1. What kind of application is it? UI client (mobile/desktop) → MVVM. Server-side web → MVC. API or backend → Layered, Hexagonal, Clean or Vertical Slice.
  2. How long will it live and how much will the business change? Prototype or simple CRUD → Layered. Complex rules and long life → Hexagonal / Clean.
  3. How big is the team? A few people → the simplest thing that works. Many teams → explicit boundaries (Vertical Slice, modules).
  4. What budget and operational maturity do you have? Little → modular monolith, not microservices.
  5. Is there a measured bottleneck? Without data, don't optimize architecture by gut feeling.
  6. How many different clients consume the backend? Several (web, mobile, third parties) → consider BFF.
  7. Hexagonal, Onion or Clean? They share the same idea (domain at the center) and differ in vocabulary and degree of prescription: see the comparison.

Application architecture (how you organize code) is independent of deployment style (how you run it). You can have Hexagonal inside a Modulith or a microservice. To decide between Monolith, Modulith and Microservices, see the comparison.

  • Layered (N-Tier) — Organizes the application into layers with unidirectional dependencies: Presentation → Application → Domain → Infrastructure.
  • Hexagonal (Ports & Adapters) — The domain defines ports (interfaces); every external actor (API, DB, queue, tests) reaches it through an interchangeable adapter.
  • Onion Architecture — Concentric layers with the domain model at the center; dependencies point inwards and infrastructure sits at the edge.
  • Clean Architecture — Organizes code into concentric layers where the domain is the center and nothing from the outside touches it.
  • 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.
  • Comparison: Layered, Hexagonal, Onion, Clean and Vertical Slice — How the most used application architectures are alike and different, and how to choose between them.