Layered Software Architecture

This paper is published under the terms and conditions in the footnote.


Most of what is written about design patterns is written with enterprise applications in mind.

These applications are usually client-server in nature.

Users, who require or enter data, interact with client-side components.

Client-side components send queries and commands to server-side components, which access the application’s state data.

This paper outlines the pattern called a Layered Software Architecture.


Layered Software Architectures. 1

Enterprise application software layers v. Platform tiers. 3

Enterprise application software layers v. Communication stack levels. 4

Open and Closed Layered Software Architectures. 4

Appendix 1: One reader’s specific layer software architecture. 4

Appendix 2: Enterprise architecture as a layered architecture. 5

Appendix 3: Some historical background. 6


Layered Software Architectures

The essential principles of the layered software architecture pattern are:

·         The components of a system are divided into hierarchy of layers, each responsible for a different kind of work

·         A component in one layer can request work from components in the same layer or a lower layer, but not a component in a higher layer

·         Communication upward must be by reply to a request, or by an indirect messaging mechanism of some kind


For example, in 1979, Keith Robinson proposed a 3-layer software architecture for enterprise applications.

This architecture represented what was then emerging as a de facto architecture.

It was later adopted and promoted by the UK government in their structured design method, using this terminology:

1.      External design

2.      Conceptual model

3.      Internal design.


Note that the conceptual model included both events and entities.

A customer account exemplifies an entity - a thing with attributes and continuity of identity.

Such a persistent entity represents the latest state reached in a life history that advances event by event.

Credit and debit transactions exemplify events – things that happen and affect one or more entities.

Events, as well as entities, are fundamental to what was then called a conceptual model.


In 1986, under Keith's direction, I wrote a paper for the UK government on the need for a process-data interface between conceptual model and internal design layers.

It was noted that one may introduce an event/enquiry layer between external design and conceptual model.

An event handler would be responsible for invoking transaction start, commit and rollback operations.

The table below maps our structured design terminology to more modern terms.

Structured design terms

You might now call

1. External Design

User Interface or Presentation Layer

Event/enquiry handlers

Service Layer

2. Conceptual Model

Business Logic or Domain Layer

Process-Data interface

Data Access Layer

3. Internal Design

Database Structure


Many variations have been published since.


In 2003, Eric Evans described a 4-layer architecture for object-oriented Domain Driven Design.

Layer name


1. User Interface (aka Presentation) Layer

Responsible for showing information to the user and interpreting the user’s commands.

The external actor might be another computer system rather than a human user.

Application Layer

Defines the jobs the software is supposed to do and directs the domain layer to do work.

Responsible for tasks that are meaningful to the business or necessary for interaction with the other applications.

This layer is kept thin.

It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down.

It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or [of?] the program.

2. Domain (aka Model) Layer

Responsible for representing concepts of the business, information about the business situation, and business rules.

State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure.

3. Infrastructure Layer

Provide generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, etc.

May also support the pattern of interactions between the four layers through an architectural framework.


Eric Evans’ example:

Layer name

Layer name


1. User Interface (aka Presentation) Layer

Application Layer

Funds Transfer App Service:

1. Digests input (e.g. XML request)

2. Sends message to domain service for fulfilment.

3. Listens for confirmation.

4. Decides to send notification using infrastructure service.

2. Domain (aka Model) Layer

Funds Transfer Domain Service:

Interacts with necessary Account and Ledger objects

Makes appropriate debits and credits,

Supplies confirmation of result (transfer allowed or not, etc.).

3. Infrastructure Layer

Send Notification Service

Sends emails, letters, etc. as directed by application layer.


See appendix 1 for one reader’s interpretation. More elaborate layering is possible. I have seen as many as 11 layers.


Note that OO programmers tend to regard the database as “infrastructure”.

The database management system is certainly infrastructure, but the database structure it contains is usually business specific

Business terms, concepts appear in the database schema and in database views.

Business logic appears in query access paths, and (outside of domain driven design) transaction scripts and stored procedures.

Enterprise application software layers v. Platform tiers

In the 1980s, business computing hardware architecture evolved from a mainframe to a multi-tiered structure such as:


Note that a layered software architecture and a multi-tier platform architecture are separate concepts.

A layered software architecture is a logical pattern rather than a physical deployment architecture.

One platform tier may host several layers.

It is harder to deploy one software layer over several platform tiers, since the platform tiers are optimised to support specific kinds of work.

Enterprise application software layers v. Communication stack levels

The network communication stack is a special kind of layered software architecture

It is typically presented along these lines:


Three questions run through discussion of software architecture, and often confuse it.

·         Which layer of the software architecture is responsible for what?

·         Which level of the network communication stack is responsible for what?

·         What is logical and what is physical?

Open and Closed Layered Software Architectures

A closed Layered Software Architecture does not allow a layer to be missed out.

A component in one layer can call only components in the same layer and the next layer down.

That is the normal expectation when software layers are mapped to platform tiers.

It has a downside, since middle layer components may have little or nothing to do but pass messages up and down.

(Like middle managers in a large hierarchical organisation structure).


An open Layered Software Architecture allows layer skipping, which can reduce complexity and response time.

For example, while update commands pass through a layer of OO code on an app server, queries might go straight to a database server.

An Open Layered Architecture

User Interface



OO Domain Layer


Object-Relational Mapping


Relational Database

Appendix 1: One reader’s specific layer software architecture

Below, a reader describes the software architecture he applies in practice.

I believe it can be mapped to Evan’s terms as shown below.

Evans’ terms

Reader’s terms

User Interface (aka Presentation) Layer

User Interface Components



Application Layer

Domain (aka Model) Layer


Application layer

Domain layer


Infrastructure Layer




 “First, I divide every application thus:  

·         The client-components are User Interfaces or User Interface Components that connect to the API of the server-component - typically sending Commands and executing Queries.

·         The server-component contains all the logic and query-capabilities and forms the integration-point for other application (in other words, it exposes an API).  


The server-component can then be divided up into three logical layers:


Server.Api (aka Service Layer or Interface Layer as I would call it)

This layer is the point of all incoming connections. 

It contains the API and is responsible for receiving all messages and returning results or acknowledgements.  

It validates all incoming message contents, and performs security checks.  

It may also manage other non-functional features like performance monitoring, logging, etc.  

In fact, this layer pushes each incoming message into a pipeline which can be customized to your needs.

Each stage in the pipeline performs a specific task (validation, security, error-handling, performance monitoring, etc.).


Server.BusinessLogic (aka Business Logic Layer)

This layer contains message-specific handlers that implement (or delegate) all business logic for Commands and Events. (Queries skip this layer).

The Service Layer will pass on each message that makes it through the pipeline to the appropriate handler.  

Since the Business Logic layer executes all business logic - thereby changing data or system state.

It is also responsible for publishing events as the changes are made.  

The Business Logic Layer can itself be divided into two 'sub layers' if you will:  

·         The Application Layer - Message Handlers -

·         The Domain Layer -  Transaction Script or Domain Model (DDD).


Server.DataAccess (aka Data Access Layer)

This layer contains all code that fetches and stores the application data.  

This can either be to serialize/deserialize aggregates, entities and events to support the Business Logic Layer, or just to return query-results.  

Thus, where the Service Layer is passive or accepts incoming connections, the Data Access Layer actively connects to databases, services or other applications to get some data.  

Preferably it only connects to a private data store, though, to achieve maximum run-time independence.”

Appendix 2: Enterprise architecture as a layered architecture

It is normal to divide enterprise architecture into domains, and arrange them in layers akin to software layers.

This can be seen in industry standards like ArchiMate (a modelling language) and TOGAF (a management framework).



ArchiMate core concepts

TOGAF core building blocks



Business services

Business services


Business roles

Business functions & roles




Application services

Information system services


Application components

Application components




Infrastructure services

Platform services


Nodes (devices & system software)

Technology components

Appendix 3: Some historical background

An ANSI/SPARC paper in the 1977 proposed a 3-schema data architecture.


Keith Robinson of Infotech Ltd (the Gartner of the day in the UK) saw that this data architecture had implications for software architecture.

In 1979, he proposed a three-layer software architecture for enterprise applications.

His idea was to encapsulate data structures processed in lower layers behind services offered to the layer above.

The table below captures the essence of Keith’s proposal and aligns it with today’s terminology.



Keith’s terms

In today’s terms

External design

Input and output data flows

User Interface

I/O Functions

Use cases / Sessions

Conceptual model

Event & Enquiry processes

Command and Query operations

Entities (as in an LDM)

Entities (as in a Domain Model)

Internal design

Logical read and writes

Data abstraction services

Database records

Database tables


The entities were exactly as specified in a logical data model.

Keith used a kind of interaction diagram to show how each event and enquiry process accessed one or more entities.

It was assumed that the events would be implemented procedurally as transactions acting on a database.

All this preceded what people now call Object-Oriented design methods.


By 1980, Keith was teaching his approach, called the “Infotech System Design Method”, in a two-week course.

A year or two later, he joined John Hall as a leading light in the development of the UK government’s Structured Systems Analysis and Design Method (SSADM).

This methodology was geared towards defining database transaction processing systems to support business activities.

In 1986, the UK government recognised they could reorganise SSADM around Keith’s 3-layer software architecture.


Around 1990, Keith noted that several types of event may trigger the same operations on one or more entities.

Wherever two or more events share the same effects on one or more entities, a common reusable process (a “super event”) could be factored out.

This approach to software reuse was explored in a book called “Object-Oriented SSADM” (Prentice Hall, 1994).

Despite the term “Object-Oriented”, reuse of components in the business logic layer was achieved by delegation rather than inheritance.



Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0           25/04/2015 14:33

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see