C4Model: Architecture diagrams for everyone
The C4 model allows representing a software system with a set of diagrams that each describe in depth a different level of detail, oriented towards a specific target audience.
Intro
The C4 model allows representing a software system with a set of diagrams, each describing in depth a different level of detail. These different levels help to communicate abstract ideas visually and from different perspectives, so that stakeholders or those interested can delve into and explore the details of the parts that interest them the most.
In C4, each “C” represents a different type of model with a different level of detail:
- context
- containers
- components
- code
We could say that the C4 model is a way to create maps of your code, with varying levels of detail, in the same way you would use something like Google Maps to zoom in or out of an area of interest.
Context diagrams
Context diagrams provide the general public with a broad overview of the entire system. The internal workings and technologies are not significant at this point. These diagrams should give a general description of the system: what it does, who uses it, and with which other systems it interacts.
These diagrams are good to share with non-technical audiences because they can help the general public understand the scope of the project, who the users are, and even see themselves reflected in the diagram.
To create a context diagram, we can use an initial box to represent the system in the center. Around this central system, we can use simple shapes to represent people (users, customers, actors, roles, etc.), and other boxes to depict systems that interact with it; finally, we should also include the relationships between them.
Container diagrams
Once we understand how our system fits into the overall information systems environment, the next step is to expand the system’s boundaries with a container diagram. A “container” might be a server-side web application, a client-side application, a desktop application, a mobile application, a database, a server-side application, a file system, etc. It’s crucial to understand that when we talk about containers, we’re not referring to a Docker container; in our diagram, a container represents an application or a data store. Something deployed independently.
The container diagram displays the high-level software architecture and how responsibilities are distributed among different components (information containers or code executors). It also shows the technology and how containers communicate with each other. It’s a simple diagram, focused on high-level technology, useful for both software developers and support and operations staff.
This diagram is thus aimed at technical personnel both inside and outside the software development team, including software architects, developers, and operations/support staff
Component diagrams
Next, each container can be further expanded and decomposed to identify the main structural components and their interactions through component diagrams.
The component diagram displays how a container is comprised of a series of components, what each of them is, their responsibilities, and technology/implementation details. An important point to note here is that all components within a container typically run in the same process space. In the C4 model, components are not separately deployable units.
This diagram is intended for Software Architects and developers, and it’s not recommended for most teams. The suggestion is to only create component diagrams if they add value, and we should consider the possibility of automating their creation to generate this level of documentation automatically.
Code diagrams
Lastly (though not really the last, it is the final level in the current series), you can zoom into each component to show how it’s implemented as code, using UML class diagrams, entity relationship diagrams, or the like.
This is an optional level of detail that is typically available in any development tool. Ideally, this diagram would be automatically generated by such tools, and one should consider showing only those attributes and methods that allow telling the story they wish to tell. This level of detail is not recommended except for the most significant or complex components.
To be honest, I don’t use this kind of diagram because I believe it’s a detail that isn’t necessary or hasn’t been needed before when undertaking a new feature of a system.
TL;DR;
The C4 model breaks down the representation of software systems into different levels of detail:
Context Diagram: Provides a global view of the system, showing what it does and how it interacts with other systems and users. Ideal for non-technical audiences.
Container Diagram: Expands the system’s boundaries by showing individual applications or data stores. These are not Docker containers, but representations of applications or databases that are deployed independently. This level focuses on high-level technology and is useful for developers and support staff.
Component Diagram: Further decomposes each container, showing individual components within it. It’s aimed at architects and developers and should only be created if it adds value.
Finally, you can zoom into each component to display its code implementation, though this detail is often optional and more technical, ideal for key or complex components.
Conclusion
The C4 model provides a framework for visualizing and documenting software systems at multiple levels of detail, catering to different audiences. From a global perspective with the Context Diagram, which is accessible to non-technical audiences, to more detailed levels with the Container and Component Diagrams, which are essential for developers, architects, and support staff. Additionally, the model allows, if desired, to delve into the code level for key or complex components.
