Architecture is a vital aspect of all systems, and applications, serving as a blueprint for engineers which defines behaviour and structure. There are numerous architectural patterns out there and they can be used on different levels of a system. In fact, a single system can use multiple architectural patterns!

As a digital consultancy, at gravity9 we have a rich history and heritage of development, picking the best architecture for the job.

In this series of articles, we’ll introduce some of the most popular system architecture around. We’ll look at why they’re popular, where they’re useful and where they’re less useful.

Introduction – the Raw List

When first drafting this guide we had a list of architectural patterns, raw and unorganised. Not all architectural patterns can be directly compared, for example, where one can be applied to multiple components of a system, another might only be used in a single component, relating only to its internal structure.

To help navigate our series of system architecture articles, we first wanted to try and organise them: to provide a visual aid and classification that explains more about their purpose and strengths against others (both alike, and unalike). We want to focus on patterns of a similar level, allowing us to compare them more easily, and highlight their pros and cons.

Initial Classification

The first characteristic we used for classification was its scope.

As mentioned, some architectural patterns can be applied to single-deployment units, like the ASP.NET Core application.

On the other hand, architectural patterns can also describe the structure of an entire system.

Above, you can see the initial classification of the architectural patterns which are divided into:

• System Architectures: These define structure and orchestration of multiple components.

• Application Architectures: These define the structure of a single component.

Two-Dimensional Classification

With a broad distinction between system architecture and application architecture, we needed a way to drill down further and compare architectures of the same group.

A two-dimensional classification was created which considers two characteristics:

1. Architecture Scope: This aims to define the scope of the architecture – how broad its utilisation can be – and can differ from a single-deployment unit to an entire organisation!
2. Abstraction Level: This aims to define whether the architecture solves a specific issue (e.g. auditability) or if it is highly abstract and defines the structure and boundaries of a systems’ components.

This approach allows us to map the nature and scope of multiple distinct architectures more neatly.

Wrapping Up

When we began this exercise, we knew we wanted to write about popular architectures, but it quickly became apparent that we’d need to bring some order to our list, in order to effectively do that.

Some are related directly to code, some are not. In order to be consistent, we’ve separated out both system and application architecture and – for this first run of articles – we’ll be focussing on system architectures and may revisit application architecture in a future series.

We’ll kick off with the first in the series, Microservices, shortly – so be sure to check back soon.