N-Tier Architecture

A key requirement of software architecture is to provide structure and order to a code base, an applicable adage could be "a place for everything and everything in its place".

The major tool that can be deployed to achieve this is to define clear and distinct layers through the code.

These layers must have a clearly defined purpose and their role should be clear and unambiguous.

This often is not as straightforward as you might think, certain pieces of functionality often slip through the cracks or are not easily compartmentalised.

But aside from these cross cutting concerns quite often the structure of software can be divided into four main layers.

Presentation

The majority of software products have a UI, a mechanism by which data can be shown to a user and their interaction with it can be captured.

A presentation layer should be solely concerned with the logic and implementation of how data will be rendered, it should make no decisions on what will be shown.

The data to be shown may very well require processing to transform it into a more appropriate form to be rendered but this processing should not contain any business logic that changes the data within the context of the domain.

It should be a conduit to capture user interaction but should have no logic that processes or actions this interaction aside from passing it down the line to a layer that does contain this knowledge.

Application

The purpose of the application layer is to provide a shell or container for the other layers to exist in.

It provides the structure necessary for the code to execute in the target platform.

In the context of GRASP classes in this layer are often referred to as Controllers. They should provide the necessary glue to combine all the other layers to produce a working application.

No logic exists in this layer aside from the knowledge necessary to operate in the chosen platform.

As much as possible this layer should be boiler plate code.

Business Logic

This layer defines the operations and functionality relevant to the domain that the software represents.

This functionality is not tied to the implementation of the presentation layer, it represents the end to end processes that your software is designed to provide, this functionality can be visualised in any number of ways.

The opportunity for re-use for this layer across your software product suite is high and should be extremely testable, if layering is being effectively implemented this layer will be key to ensuring that your software is operating properly.

Data Access

Just about all software involves the processing and presentation of data.

There are a plethora of different methods and technologies that can be used to store this data, the purpose of the data access layer should be to abstract this potentially complicated area of code and provide a consistent view of the domain.

This layer will very often also include providing access to data accessed via APIs or services and will likely be asynchronous in nature.

The only logic in this layer should be how to retrieve data and represent it within the context of the domain, not what should be done with it or how it should be presented to the user.

As well as defining what these layer do and don't do its important to adequately define the interface between them. Effectively doing this leads to testability, extensibility and the possibility of re-use.

The antithesis of the layered approach is often referred to as spaghetti code, categorised by the inability of those that work on it to fully understand the structure of the code or even begin to think about extending its purpose or making improvements.

There is a reason that good software engineers often hate untidiness or disorder, a well organised and structured code base delivers clear and unambiguous value.

When assessing your code base be sure to evaluate if you can clearly draw rings around these four main layers and not see any bleeding of functionality across these boundaries, "a place for everything and everything in its place".