C4 Modeling — Do you see what I see
One of the challenges of being a software architect is conveying the architecture to the team in an efficient manner.
Imagine yourself as an architect, who has just designed an elegant system for a complex problem. You’ve spent hours on the whiteboard and finally figured out how it all fits together.
While you’re somewhat proud of your solution, a slight panic starts to creep up. There is a question looming inside of your head —
“How do I make my team understand the solution?”
You break a cold sweat when you realize, it’s not only the dev team, but other business stakeholders also need to be explained the solution. You panic a little.
Then you remember, in a long-lost article, you had read about a modeling technique that allows us to define software architecture at various levels of detail, such that different audiences can understand architecture at the level of detail that they need.
C4 modeling technique helps us to view the solution in a top-down fashion. Starting from the bigger picture and then diving deeper into the details. According to C4, there are four levels of a system.
Level 1 — Context (System) Diagram:
This is the bird’s eye view of the system. It defines what a system is, what it does, which other systems it interacts with, and who uses the system. Essentially it scopes the solution to who is/are the user(s) and what problem(s) is/are being solved by it.
Level 2 — Container Diagram
(From the official docs) Not a docker!
Container here refers to any Web Application, mobile application, serverless function, database, microservices, etc that a system would use. It is the zoomed-in view of a part of a software system. Each of these applications or services is represented with a container and the interactions between them are shown at a high level.
Level 3 — Component Diagram
Next we can zoom in and decompose each container further to identify the major structural building blocks and their interactions.
The Component diagram shows how a container is made up of a number of “components”, what each of those components are, their responsibilities, and the technology/implementation details.
Level 4 — Code Diagrams
If we dig deeper, then we can see how each component is implemented as code use diagrams such as entity-relationship diagrams, class diagrams, etc.
This is usually a little too much detail, so we try to focus on the attributes and methods which allow us to tell the story of the component. Unnecessary details are omitted.
Mostly, the Level 4 diagram is only created when needed and the top 3 diagrams suffice the need.
C4 modeling is a great way to design software. Not just for documenting the software, but it allows us to dig into the problem from a top-down approach which allows clarity in thought leading to better solutions.
References:
- https://c4model.com/ — The official website for C4.
