C4 Model: Describing Software Architecture
The point behind a presentation of Visualizing Software Architecture, by Simon Brown, was that we need to standardize the way software developers communicate with each other in respect to our discussions of software architecture.
As part of Simon’s consultation, one exercise he gave to software architects was a simple task to white board the architecture of a software system. The results he received varied immensely, and there was never a defacto standard format that he received from this exercise. When inspecting the feedback from the participants, the general answer was that it was easy to come up with the design, but difficult to properly put their ideas onto paper, or white board in this case.
Simon sought to start a movement by defining a set of organizational rules to help us describe our software architecture with a set of standard terminologies. His work has led to C4 Model, which stands for Context, Containers, Components, and Code. Each C represents a different level of abstraction that allows us to create a separation of specificity of our system. Each level of abstraction can serve to describe how granular we want to describe it to serve different purposes — Do we want to describe the overall structure of our systems to IT infrastructure team, or do we want to define the dependency of an existing service we are changing.
System Context
The System Context level defines the highest level of abstraction of our architecture. In this level we describe components by separation of complete systems, where a system is a collection of related “containers” or deploy-able applications. This level is useful for describing the overall structure of the complete system and what the high level integrations between systems are. This can be useful for audience to make larger non-technical decisions to match the owner’s initiatives.
Layer Terminology: System, People
Containers
The container level defines the layer where we start to describe boundaries between each deploy-able application. By organizing our structure into containers, we can start to define the structure of a system. This level is helpful for the main development team of the system and technical parties evaluate changes and diagnose issues.
Layer Terminology: Deployments, Hosting, Resources, Application, Database, API, Website
Components
The component level defines how a container is logically split up between its different parts, so that you can inspect the general design of a container. This view is useful to see which technologies implement specific parts of a container. This level is generally used for the planning stage of developers as they start to work on features. The structure is usually defined by the software architect.
Layer Terminology: Frameworks (ASP.NET, Entity Framework, Serilog, Autofac, etc), Libraries, Projects
Code
The code level defines how the components are actually implemented.This level can be considered optional by the standard, due to its difficulty to maintain, and little advantage it brings over having the code base itself.
Layer Terminology: Classes, Interfaces, Design Patterns, Languages
Originally published at jameslouiecs.blogspot.com.
