Layered Architecture

Layered architecture separates responsibilities into horizontal layers such as presentation, application, domain, and infrastructure.

Core Idea

The system is organized into stacked layers where each layer has a specific responsibility. Each layer depends only on the layer directly below it. This creates a clear separation of concerns and makes it straightforward to understand where each type of logic belongs.

When to Use

• Applications with well-understood CRUD operations
• Small to medium teams working on a single application
• Systems where the domain logic is relatively straightforward
• When you need a familiar, widely-understood structure
• As a starting point before the architecture needs to evolve

When to Avoid

• Highly complex domain logic that deserves isolation
• Systems with many external integrations that blur layer responsibilities
• When teams need to deploy parts of the system independently
• Applications where the layer structure forces unnecessary indirection

Benefits

• Simplicity: Easy to understand and explain to new team members
• Separation of concerns: Each layer has a clear responsibility
• Testability: Layers can be tested in isolation by mocking the layer below
• Familiarity: Most developers have experience with this pattern
• Tooling support: Many frameworks are designed around this structure

Trade-offs

• Rigidity: Strict layering can force unnecessary abstractions
• Pass-through layers: Layers that add no logic but must exist for structural compliance
• Horizontal growth: As features grow, layers become large and hard to navigate
• Coupling to the database: Often the infrastructure layer drives the design
• Change amplification: A single feature change may require touching all layers

Common Failure Modes

• Big Ball of Mud: Layer boundaries erode when the team is under pressure, leading to cross-layer dependencies
• Anemic domain model: Business logic leaks into the application or presentation layers, leaving the domain layer as mere data containers
• Layer skipping: Higher layers bypass intermediate layers for convenience, breaking the dependency rules
• God services: Application layer services grow unbounded because there is no vertical decomposition

Related Styles