C4 Model: Four Abstraction Layers for Software Architecture Visualization

1. Common Abstraction Over Common Notation

In electrical engineering, resistors have multiple symbols but refer to a single real-world object. Similarly, software engineering has shared notations like UML, SysML, and ArchiMate, but terms such as "component" remain ambiguously defined. The UML specification defines a component as a modular unit with well-defined interfaces, replaceable in its environment, while a dictionary defines it as a part of a larger whole. For a system comprising a web application and a database, both statements can be true: "The web application is a component of the software system" and "The web application consists of several components." The same word describes two entirely different abstraction levels, leading to miscommunication. Unifying notation is important, but the software industry's more fundamental problem is the lack of a shared vocabulary for structurally thinking about and describing software systems. Before we can have a universally understood symbol like the resistor symbol, we first need a shared set of abstractions.

2. The Four Abstraction Layers

The C4 model uses static structure viewed from four abstraction levels.

In one sentence: A software system consists of one or more containers (applications and data stores), each container contains one or more components, and each component is implemented by one or more code elements (classes, interfaces, objects, functions).

Software System

This is the hardest to define because every organization uses different terms—application, product, service. At the highest abstraction level, a software system describes the thing that delivers value to users, whether human or not. It includes both the system you are describing and the external systems it depends on. Often, the software system boundary aligns with the team boundary, and everything inside is typically deployed together. Conversely, product domains, business capabilities, and feature teams are usually not software systems in C4.

Container

In C4, a container represents an application or a data store—something that must be running for the overall system to work. A container is a runtime concept , circling a piece of executing code or stored data. Each container is independently deployable and runnable; containers communicate via inter-process or cross-network remote calls.

Component

"Component" is a heavily overloaded term in software, but it fits well for describing the internal structure of an application container. In C4, a component is: a grouping of related functionality encapsulated behind a well-defined interface, running inside a container. It is essentially a set of code, an abstraction above code-level building blocks. A component is not an independently deployable unit; containers are independently deployable, while components run inside a container. All components within a container share the same process space and communicate via in-process method calls.

Code

This layer is the internal implementation of a component, using the programming language's basic building blocks: classes, interfaces, enums, functions, objects, etc.

3. The Four Core Diagrams

With these four abstractions, you can draw diagrams at four levels to visualize the static structure. This is the origin of the name C4: Context, Containers, Components, Code. Think of them as a set of maps that you can zoom in and out of to tell different stories to different audiences.

System Context Diagram

The starting point for understanding any system. It shows how the target system fits into the surrounding world, clarifying the system's scope, who uses it, what they do, and which external systems it depends on.

Container Diagram

Zooms one level inside the system boundary, showing the containers within the system. It illustrates the overall shape: how responsibilities are divided, how containers interact, and what key technology choices have been made.

Component Diagram

When engineers need more detail, zoom further into a single application container to show its internal components, again describing responsibility allocation, interactions, and technology choices.

Code Diagram

Finally, zoom into a single component to show which code-level elements implement it. This layer is essentially a UML class diagram.

4. Three Supplementary Diagrams

C4's name comes from the four static structure diagrams, but three supplementary diagrams are also useful.

Dynamic Diagram

When you want to show how elements from the static model (systems, containers, components, code) collaborate at runtime to implement a user story, use case, or feature, use a dynamic diagram. The most common form is a UML sequence diagram, but it is not the only option.

Deployment Diagram

Shows how the system and container instances from the static model are deployed onto infrastructure in a specific environment. Applicable to both on-premises and cloud deployments, bridging the gap between those who write software and those who run it.

System Landscape Diagram

The previous four diagrams focus on a single system. In reality, systems never exist in isolation, so a system landscape diagram provides a map of all software systems within a chosen scope (organization, department, business domain).

5. Usage Recommendations

Several practical tips are worth noting:

Different abstraction levels target different audiences. The System Context diagram is high-level enough for almost anyone involved in building software; the Code diagram is only for engineers. This characteristic can be leveraged: diagrams at different levels age at different rates —Component and Code diagrams change more frequently and require more maintenance than System Context and Container diagrams.

Despite the name "C4", you do not need to use all four diagrams . The four layers exist for completeness, allowing you to zoom from a single box down to code. Experience shows that System Context and Container diagrams are sufficient for most engineering teams . Whether Component and Code diagrams are worth the effort depends on the cost of creating and maintaining them.

1. The C4 Model for Visualising Software Architecture 第一章和第二章 ↩︎