Architectural Layers

Photo by Max van den Oetelaar on Unsplash

Last time we discussed the purpose of software architecture. Readers may recall that a well-designed architecture allows us to

• make system changes with relative ease,
• build systems that are simple to understand, and
• maximise code reusability.

Today, I’d like to outline the various layers that compose such a ‘good’ software architecture.

A lack of clearly designed structure in our programs is evident to all: The code is a convoluted mess; features are hard to implement or change. And when it’s especially awful, developers don’t even want to touch those sections of code. They’ll know that those parts are particularly fragile and confusing in their unnecessary complexity.

On the other hand, well-implemented architecture displays opposing qualities: The code is easy to read; the structure is clear and self-explanatory, automated tests verify the validity of the requirements, and so on.

The following illustration outlines the different layers of a well-designed software architecture:

Let’s explore the layers from the bottom, low-level detail up:

• Clean Code – Concerns about how to structure code at the function and data structure level. Many of my recent programming tips were at this layer: Function length advice, code readability recommendations, etc.. Readability, tolerance to change and reusability apply as much here as at other levels.
• SOLID Principles – Here, we have principles specifying how we should group our functions and data into cohesive modules. The SOLID Principles also advise us on how modules ought to interact with each other.
• Component Principles – The Component Principles are self-similar to the SOLID Principles but as applied to the unit of deployment – Components (eg. DLLs for .NET, JAR files for Java, etc.)
• Clean Architecture – The highest, most abstract level of how to structure an entire software system, beyond deployable components. Here we are managing concepts of policy versus mechanisms. The ‘Clean Architecture’, initially proposed by Robert C. Martin, is a definite approach to overcoming design problems at this high level. Other architectures, such as Onion Architecture or Hexagonal Architecture, exist, but they are almost indistinguishable from the Clean Architecture.

I intend to cover off these layers in detail another time.