Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

StyleChapter II · Styles & patterns · Building block 1 of 8

Layered Architecture

A layer architecture ranks code by type of responsibility. Dependencies follow a defined direction.

By Michael Meierhoff · Meierhoff Systems

  1. LayerLogical group with a responsibility.
  2. DirectionCalls only run down.
  3. Layer ≠ AnimalLayer logical, animal physical.

Context

Why this is important

Without layers, form, flow, business rules and database access mix in the same code. Layers arrange this logically, Tiers on the other hand physically on their own computers or processes. The checkout has four layers, all in the same deployment.

This building block explains layers and their dependency direction. For business module boundaries, see Modular Monolith.

At a glance · Layers with a downward direction

Four stacked layers from presentation to infrastructure; calls only go down, never up.
Shop example · Layer stacks

Where does that belong?

The checkout of the modular shop monolith accepts an order, checks business rules and saves the result in SQL.

This is how you read the picture

  1. Layer The four areas of presentation, application, core and infrastructure, such as web UI and SQL adapter.
  2. Direction The arrow from checkout application to order rules is allowed, that from order rules to web UI is not allowed.
  3. Layer ≠ Animal All four shifts are in the same shop deployment, i.e. in a single animal.
  1. PresentationWeb UI
  2. ApplyCheckout application
  3. Specialist coreOrdering rules
  4. InfrastructureSQL adapters

Owned in PresentationAn input check belongs to the form and gives the user immediate feedback.

Select a task or call; the responsible layer lights up, a call appears as an arrow.

Benefits & limitations

Helps if:

  • Layered architecture organises tasks and permitted calls around different technical reasons for change.
  • Multiple input paths use the same application rules as soon as a common application layer bundles its flow.
  • A domain layer that keeps transport and storage details out of its rules enables independent business rule tests.

Boundaries

  • Technical layers cut across the business domain: A business change such as picking up touches all layers. Therefore, the layers in the shop are within the modules, see Cohesion and Modular monolith.
  • Architecture Sinkhole: layers merely pass calls through without making decisions. Remove layers that have no responsibility of their own.
  • In small systems, rigid layering can cost more than it clarifies. Add layers when recurring change problems justify them.

In practice

  1. Assign each decision to a responsible layer. Record where transport is translated, the flow is coordinated and business rules are checked, so responsibilities remain clear in the code.
  2. Define permitted dependency directions and check them automatically. Inner rules should not import presentation code; an architecture test reveals reverse dependencies early.
  3. Trace changes across layer boundaries and check whether each handover serves a distinct purpose. Where useful, connect domain boundaries to Module Boundaries and Dependency Inversion.
Read the detailed explanation

Layers group tasks by role and define which layer may call another. Common separations distinguish presentation, application flow, business rules and technical storage. This arrangement is useful when each layer has its own responsibility.

Dependency direction determines which layers may know about others. A rule can then be tested independently of its user interface; independence from storage mechanisms requires the core to avoid direct dependencies on the infrastructure layer. Domain module boundaries complement this technical organisation and establish who has authority to change each set of data.

Separation of Concerns assigns business responsibilities; Dependency Inversion controls dependencies between the core and technical implementations.

In strict layering, a layer may call only the layer directly below it; relaxed layering also permits calls to deeper layers. In the illustration, the application calls the SQL adapter, so the shop uses relaxed layering. Dependency Inversion and Hexagonal Architecture show how to point dependencies towards the business core. A layer is a logical grouping in code; a tier is a physically separate part of the deployed system.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    You select “Checkout application calls order rules”. Is the call allowed, and where does the arrow point?

    View the solution with justification

    It is allowed. The arrow points from the application to the specialist core, i.e. in the intended direction.

  2. ApplyingTransferred to a new situation

    New rule: discount from three cups. What layer does it belong in, and what remains in the Web UI?

    View the solution with justification

    The discount rule belongs in the expert core, because it applies to all access. The web UI only shows the discount, the application triggers the examination.

  3. EvaluateWeighing an alternative

    A team wants to put Web UI, application and SQL on their own servers (Tiers) in order to separate cleaner. How do you rate that?

    View the solution with justification

    Advantage: separate scaling and hedging per part. Disadvantage: network calls, more operation and more sources of error. Clean separation is already created by layers in the code. Do not create Tiers until there is a specific operational reason.

Explore further

These optional deepenings complement the learning goal of this page.

MVC · Model-View-Controller

MVC (Model-View-Controller) organises interaction within a user interface: the Model holds the state and rules to be presented, the View displays that state, and the Controller processes input and triggers appropriate actions. MVC complements layered architecture on the UI side; it does not by itself define the application's overall dependency direction or domain module boundaries. The exact division varies by framework.

For testingAssign an input in the shop checkout: The view shows shopping cart and validation errors, the controller processes the click on “Order” and calls up the application flow, the model provides the required state. Check that the View does not execute an order rule or database write operation itself.

Further building blocks

PrinciplesSeparation of responsibilitiesSeparation of responsibilities assigns tasks with different reasons for change to suitable building blocks.Opening PrinciplesDependency InversionDependency Inversion aligns the domain core with stable contracts instead of concrete technical tools.Opening Styles & patternsModular monolithA modular monolith separates domains within a single application deployed as one unit.Opening

References

Continue on the learning path

Next in Styles & patterns: Modular monolith.

8 Building blocks

Continue withModular monolith