Basic architectural terminology

Content:

  1. Introduction
  2. Tiers vs layers
  3. Tiers examples
  4. Layers
  5. Layers examples
  6. MVC and layers
  7. Classes and layers
  8. SOA and services
  9. HA (High Availability)

Introduction:

This article introduces and discusses some basic architectural terms. The intention is to facilitate more precise architectutal discussion and definition.

Tiers vs layers:

Some texts use tiers and layers as synonyms.

I don't like that as I think that usage looses precision - and precision is important in architecture.

A different approach is to define them as:

Tiers
Tiers are logical separated parts of the application that can reside on different systems
Layers
Layers are logical separated parts of the application that must reside on same system

Which can be rephrased as:

Tiers
Tiers are logical separated parts of the application that execute in different processes (potentially on different systems)
Layers
Layers are logical separated parts of the application that execute within the same process

or:

Tiers
Tiers are logical separated parts of the application that interact via network protocols
Layers
Layers are logical separated parts of the application that interact via function/method calls

Tiers examples:

Let us illustrate with a bunch of examples.

Examples of 1 tier architectures:

1 tier architectures

Examples of 2 tier architectures including both data editing applications and chat style applications:

2 tier architectures

Examples of 3 tier architectures both fat client applications and traditional web applications:

3 tier architectures

Examples of 4 tier architectures from extended web applications to full blown SOA:

4 tier architectures

Layers:

Layers should:

Layers examples:

The classic division in layers is to divide the application tier in:

Like:

classic 3 layer

But several alternative divisions of layers exist.

One can split the Presentation Layer in a Presentation Layer (visible part of the UI) and a Control Layer (part of UI handling user actions) like:

with control layer

Certain technologies encourages this split:

I like the idea of the control layer and the ability to have different teams work on presentation layer and control layer.

Another possibility is to have a domain layer (data model) with classes used across the 3 classic layers like:

with domain layer

It sort of break with the layer concept, but it can be done in a structured way. And it can often save a lot of data conversion and moving between layers.

Another possibility is to not have the application access the database tables directly but let all database interaction go through views and stored procedures like:

with view & SP layer

This enable the DBA to change the actual table structure without requiring any application changes. It can also provide security benefits as the application can be granted access to only views and stored procedures but not the underlying tables.

Yet another possibility is the 4 tier model where a Service Layer (exposing API) is introduced (and Control Layer seems to make a lot of sense) like:

with control layer and service layer

And of course there is the model with only Presentation Layer and Data Access suitable for ultra simple data editing applications with no business logic:

simple

In these HTML 5 times it is also common to have all the UI logic out in the browser tier:

simple

There is not a single right layer model. There can be many valid layer models for a given application. What is important is to agree on a layer model and be consistent in following it.

MVC and layers:

A classic GUI pattern is MVC.

M = Model
The underlying data
V = View
Get data from model, display model to user and submit actions to controller
C = Controller
Handle actions and update model

There are two fundamental different ways of looking at MVC and layers:

Business Logic Layer as Model:

model in business logic layer without control layer model in business logic layer with control layer

Layer above Business Logic Layer as Model:

model above business logic layer without control layer model above business logic layer with control layer

I clearly prefer the second case, because:

The above also applies to MVP (Model View Presenter) and MVVM (Model View ViewModel).

Classes and layers

Layers should be loosely coupled.

A classic way to achieve this is for a layer only to expose:

to the layers above and keep all other classes including the classes implementing the actual functionality internal.

This is a somewhat oversimplified picture, but the overall concept is valid.

Applying this to the layer models described above show some interesting points.

A classic Presentation Layer + Business Logic Layer + Data Access Layer model look like:

PL+BLL+DAL model

This is a clean model with good separation between layers. The downside is that data classes exist in two layers.

One way to address this issue is to relax the "layer only use layer immediatetly below" rule to a "layer only use layers below" rule.

This allows the following sligtly modified model:

PL+BLL+DAL model with shortcut

The achieve the goal of only having data classes in one layer. The downside is the exposure of Data Access Layer to Presentation Layer.

A different way to address the issue to use the Presentation Layer + Business Logic Layer + Data Access Layer + Domain Layer model described above.

That resuly this model:

PL+BLL+DAL+DL model

The achieve the goal of only having data classes in one layer. The downside is the introduction of an entire new layer.

There are pros and cons of each model.

My preferences are:

One reason for favoring the classic model is that the two level of data classes are not identical. In fact the bigger and more complex the application becomes the more different the two level of data classes tend to be.

SOA and services:

SOA (Service Oriented Architecture) is an architecture where:

An analogy is that: SOA is for systems what procedural programming is for code.

A service is simply an application providing a single business function in a way that fit in a SOA architecture.

The open standard based interfaces are typical:

Traditional silo model:

silo model

New SOA model:

soa model

In recent years the service concept has been supplemented with the micro-service concept.

A micro-service is a small application providing a single IT function in a way that fit in a SOA architecture.

A collection of related micro-services provide a virtual service.

HA (High Availability)

Critical applications need to be available even in case of a system going down.

That requirement is achieved by introducing redundancy.

Two basic types of redundancy exists:

With load sharing multiple instances of the system is deployed and all of them actively process requests:

Load sharing model

If one system goes down then the remaining systems just continue processing.

Load sharing is also known as active-active cluster.

Load sharing is common for stateless applications (web servers, app servers etc.).

With failover multiple instances of the system is deployed but only one of them actively process requests - the rest is just standby:

Failover model

If the active system goes down then one of the remaining systems take over processing.

Failover is also known as active-passive cluster.

Failover is common for stateful applications (database servers, message queue servers etc.).

Article history:

Version Date Description
1.0 September 19th 2016 Initial version based on multiple old articles on Eksperten.dk
1.1 October 8th 2016 Add content overview
1.2 October 9th 2016 Add SOA section
1.3 May 5th 2017 Add HA section
1.4 July 6th 2017 Add more descriptive text for layers
1.5 December 27th 2017 Add section about classes

Other articles:

See list of all articles here

Comments:

Please send comments to Arne Vajhøj