←
Today's Queue
Pod
📖 Business
Layered Architecture
Fowler presents layered architecture as the foundational organizing principle for enterprise applications: separating the system into distinct layers — presentation, domain logic, and data source — where each layer depends only on the layer below it. This isn't merely a folder structure; it's a dependency rule that determines which code can call which other code. The presentation layer handles user interaction and display, the domain layer contains business rules and logic, and the data source layer manages persistence and external system communication. The power of layering is that you can understand, modify, and test each layer independently, and you can substitute implementations (swap a web UI for an API, or a SQL database for a document store) without rewriting the layers above or below.
2
Minutes
2
Concepts
+45
XP
1
How It Works
  1. The three primary layers — Fowler's canonical enterprise layers:
  • Presentation — Handles UI rendering and user input. In web apps: controllers, views, API endpoints. Translates user actions into domain operations and domain results into displayable formats.
  • Domain Logic — The core of the application. Business rules, validation, calculations, workflows. This layer should have zero knowledge of how data is stored or how results are displayed.
  • Data Source — Persistence and external system access. Repositories, data mappers, gateway classes. Translates between domain objects and storage mechanisms.
  1. The dependency rule — Each layer depends only on the layer below it. Presentation depends on Domain, Domain depends on Data Source. Dependencies never flow upward. This means changes to the presentation layer cannot break domain logic, and changes to the data source cannot break presentation code. Fowler notes that some architectures relax this to allow presentation to skip domain and access data directly, but this shortcut accumulates technical debt.
  1. Layer vs. tier — A layer is a logical separation within a single process. A tier is a physical separation across processes or machines. You can have three layers running in one tier (a monolith) or distributed across three tiers. Fowler argues that layering is always valuable; distribution across tiers should only happen when forced by scalability or organizational requirements.
  1. The domain layer as the core investment — The presentation layer changes frequently (redesigns, new platforms). The data source layer changes occasionally (database migrations, new storage technologies). The domain layer represents the business's core intellectual property and changes most carefully. Layering protects this investment by insulating domain logic from the volatility of UI and infrastructure.
  1. Common layering mistakes — Domain logic leaking into the presentation layer (validation in controllers), data access logic creeping into the domain layer (SQL in business objects), and "smart UI" anti-pattern where all logic lives in the presentation layer with no meaningful domain or data source separation.