The C4 Model for Software Architecture

This chapter gives an overview of C4 Model for Software Architecture, and how the C4 model was created as a way to help software development teams describe and communicate software architecture.

Contetx

Software architecture diagrams are a fantastic way to communicate how you are planning to build a software system (up-front design) or how an existing software system works (retrospective documentation, knowledge sharing, and learning).

The C4 modelling is used to describe and define architectures in an abstract and simple way. Designed by Simon Brown, C4 is a different way to approach modelling software development which focuses on four c’s: context (people), containers, components, and code.

C4 Model

C4 stands for context, containers, components, and code — a set of hierarchical diagrams that you can use to describe your software architecture at different zoom levels, each useful for different audiences. Think of it as Google Maps for your code.

To create these maps of your code, you first need a common set of abstractions to create a ubiquitous language to use to describe the static structure of a software system. The C4 model considers the static structures of a software system in terms of containers (applications, data stores, microservices, etc.), components, and code. It also considers the people who use the software systems that we build.

Level 1: System context diagram

System context diagram, shows the software system you are building and how it fits into the world in terms of the people who use it and the other software systems it interacts with. Here is an example of a system context diagram that describes an Internet banking system that you may be building:

Level 2: Container diagram

Container diagram, zooms into the software system, and shows the containers (applications, data stores, microservices, etc.) that make up that software system. Technology decisions are also a key part of this diagram. Below is a sample container diagram for the Internet banking system. It shows that the Internet banking system (the dashed box) is made up of five containers: a server-side web application, a client-side single-page application, a mobile app, a server-side API application, and a database.

Level 3: Component diagram

Component diagram, zooms into an individual container to show the components inside it. These components should map to real abstractions (e.g., a grouping of code) in your codebase. Here is a sample component diagram for the fictional Internet banking system that shows some (rather than all) of the components within the API application.

Level 4: Code

Finally, if you really want or need to, you can zoom into an individual component to show how that component is implemented. This is a sample (and partial) UML class diagram for the fictional Internet banking system that, showing the code elements (interfaces and classes) that make up the MainframeBankingSystemFacade component.

Notation

The C4 model doesn’t prescribe any particular notation. A simple notation that works well on whiteboards, paper, sticky notes, index cards and a variety of diagraming tools is as follows:

What is the best representation method?

There is no single correct representation method and no single “right answer.” We know from experience that we should evaluate a representation method to determine whether it will fits our needs before speending time on it.

Conclusion

The C4 model is a simple way to communicate software architecture at different levels of abstraction, so that you can tell different stories to different audiences. By using the C4 model for software architecture, you can capture just enough architecture to communicate to stakeholders and enable team understanding without having to define details that will change as your architecture changes.

References

The C4 model for visualising software architecture— Brown, Simon