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.
Contents
Layered
Software Architectures
Enterprise
application software layers v. Platform tiers
Enterprise
application software layers v. Communication stack levels
Open and Closed Layered Software
Architectures
Appendix
1: One reader’s specific layer software architecture
Appendix
2: Enterprise architecture as a layered architecture
Appendix
3: Some historical background
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 |
Description |
|
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 |
Description |
|
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.
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.
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?
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 |
|
|
Commands |
Queries |
|
OO Domain Layer |
---- |
|
Object-Relational Mapping |
SQL |
|
Relational Database |
|
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 |
|
|
|
Server.Api |
|
|
Application Layer Domain (aka Model) Layer |
Server.BusinessLogic Application layer Domain layer |
[Queries] |
|
Infrastructure Layer |
Server.DataAccess Database |
|
“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.”
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).
|
View |
ArchiMate
core concepts |
TOGAF core
building blocks |
|
|
Business |
Services |
Business services |
Business services |
|
Components |
Business roles |
Business functions & roles |
|
|
Information systems |
Services |
Application services |
Information system services |
|
Components |
Application components |
Application components |
|
|
Infrastructure technology |
Services |
Infrastructure services |
Platform services |
|
Components |
Nodes (devices & system software) |
Technology components |
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.
|
Layer |
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: http://avancier.website” 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 http://creativecommons.org