Architecture Styles: Layered Architecture

If you want to dig deeper into architecture tradeoffs I recommend Fundamentals of Software Architecture. It still stands out in 2024 for covering the most common styles, how they compare, and what questions to ask before committing to one.

Definition

Layered architecture (often called n-tier) partitions a system into stacked slices that each own a technical responsibility. A modern stack usually contains a Presentation layer (web or mobile UI), an Application/Service layer for workflows, a Domain layer for business rules, and an Infrastructure or Persistence layer for database and integrations. Each layer hides its implementation behind contracts and only exposes what the next layer needs. Well-run teams now treat layered systems as domain-centric instead of database-first: they model the core use cases first, then design persistence to support them.

While there is no fixed number of layers in this style, four layers keep showing up:

Layers physical separation

There are three common deployment options when you look at physical separation:

1. The most common is hosting the database separately from the rest of the application. Managed database services or dedicated VM clusters are perfect fits here because they isolate I/O heavy workloads.

2. The second is splitting the UI, the API (application + domain), and the database into different deployables. Teams often do this with containerized workloads or serverless frontends that call a REST/GraphQL API.

3. The last one is keeping all layers in one physical unit. This works well for prototypes or edge deployments where you rely on embedded databases or local storage.

Layers communication

The standard communication pattern between the layers is top to bottom, which means a connection from the presentation layer must go through the service/domain layers before it reaches persistence. Modern variants also allow asynchronous communication (domain events) so the outer layers do not block on slow I/O. From a communication point of view, layers can be of two types:

• Closed: The previous layer cannot bypass a layer with a “closed” label, and the request must go through it before it proceeds.
• Open: The previous layer can bypass the layer with the “open” label.

An example of all closed layers:

The connection can only go through the next layer and must not bypass it. The presentation layer cannot reach the database directly without using the business/domain layer. That isolation means a change inside a layer stays contained as long as the public contract is preserved.

Another variant introduces a few open layers. These are optional layers like logging, auditing, or shared formatting that multiple services consume. Marking them as open keeps duplication low while still respecting the main flow.

Usage: When to use such style?

This architecture style is easy to onboard and quick to evolve early on. Junior and senior engineers can reason about it, especially when the domain is still forming.

So use this architecture if:

• You do not have teams with defined responsibilities yet and want a single deployable
• You are starting your product and need to ship features before optimizing for scale
• You still do not know what your business structure is and expect the domain model to change often
• You are building a simple website or internal tool with well-bounded features
• You plan to introduce richer architecture patterns (like hexagonal or microservices) only after the product-market fit stage

Disadvantages

• Even with closed/opened cues, nothing technically stops a layer from bypassing another without strict code reviews or automated checks
• As soon as you grow into multiple teams, shared deployments slow down parallel work and increase merge conflicts
• Any change requires redeploying the entire system, so releases become risky unless you automate tests and canary rollouts
• Startup time grows with every module, and background jobs or scheduled tasks can delay deployments if not isolated
• Large monoliths make technology upgrades (frameworks, database drivers) harder because every layer must move together

Final words

Always use the architecture that makes sense to your current situation. There is nothing like “the best architecture.” Every different position requires another solution. Keep an eye on clear module boundaries, automated tests, and feature toggles so the inevitable migration to another style later (modular monolith, services, or event-driven flows) is an incremental path instead of a rewrite.

• Tags:
• Architecture
• Software-Engineering