The C4 Model was created by Simon Brown commencing around 2006. This means that it has a similar timeframe to the publication of the ICONIX Model, although ICONIX had been in development for much longer.
In my previous takedown on the ICONIX Process, I discussed the relevance of ICONIX to today’s frameworks for software design, taking into account:
- Agile processes
- Containerisation and deployment via containers
- Micro-Services
- Domain Driven Design (DDD)
In this article I will provide a similar overview of the C4 Model and link its relevance to today’s software architecture methodologies.
C4 Model Levels
The C4 model breaks software architecture down into 4 steps, or “levels”, with the implication that each level provides more detail than the level above, and less detail than the level below. The levels are:
- Context
- Containers
- Components
- Code
Similar to the ICONIX process, C4 modelling begins with abstractions, the highest level of which is the Context diagram. The context diagram shows the system under development as a single box, with the components around it (that do not form part of the software under development) as separate boxes. An example of a context diagram is shown above, taken from the C4 website.
The next level down, and where the system is first decomposed, is the container diagram. This doesn’t immediately imply that each container in C4 is the same as a “container” in Docker parlance, or even a single micro-service, however when you are building a micro-service based system then mapping micro-service containers to containers in the C4 model may well be a useful visualisation tool.
The level of detail beneath the container diagram is the component diagram. This identifies the major structural building blocks of the system. Again, these may or may not map to individual services or micro-services, but are intended as an abstraction or visualisation of how the system may be laid out. An important part of the container diagram is the representation of communication links between containers — these aren’t necessarily the same as links in a UML diagram, but rather refer to communication lines similar to those that might appear on a sequence diagram.
The final level of diagram in the C4 model is the “code” diagram”, which is fundamentally just a class diagram from UML.
Relevance
I find that the C4 model is much more relevant to today’s software architecture practices than ICONIX. The highest level of diagram, the context diagram, positions the system as a whole and although it harkens back to the “Interface Requirements Specifications” documents of the waterfall/Rational Rose era, it involves much less paperwork.
Although the container diagram in the C4 model was not initially intended by the author of C4 to map to or represent individual micro-services, using it as a micro-service diagram does lend itself to being able to visualise those micro-services in a way that is easy to explain to people both inside and outside of the software team.
The component diagram is simply a further breakdown of these containers, which I use as and when required.
I don’t see class diagrams (the “code” diagrams in C4) to be particularly relevant. Very few people work at the level of detail of class diagrams today. Furthermore, class diagrams are not software architecture, they are software design. I stated in a previous article that software architects should “do software architecture, not software design”, and I believe that these diagrams are too much design for an agile team today.
Weaknesses
The biggest single weakness in the C4 model is that it does not adequately explain the “how” or “why” of the container and component diagrams. I find that too many articles about the C4 model, and in fact the C4 website itself, do a bit of hand-waving over this issue without actually addressing it — leaving it as “an exercise for the reader” to steal a quote from probably every university level mathematics textbook ever written.
A lot of the how and why can be found in Domain Modelling. To recap, Domain Modelling is the process where the architect begins with the software requirements, builds a project glossary, identifies the highest level “nouns” in the project glossary (which become the domain objects) and drafts these into a diagram. This is the first level of static diagramming in the ICONIX process. I have another article where I explain the differences between static and dynamic modelling, and explain why static modelling is important.
C4 is clearly a static-modelling-heavy process, and so domain modelling fits in here very well. It’s a clear way to define what your software containers and components should be, and how they relate to each other. That becomes the feed-stock for the C4 model diagrams.
Summary
Better software architecture is about being able to reduce cost, improve developer efficiency, and produce software that is better and easier to maintain. The C4 model goes a long way towards achieving that result.
Implementing Domain Modelling as well as Domain Driven Design as part of the C4 architecture path can greatly achieve the goals of software architecture. I will continue this discussion in a further article.
References
The C4 model for visualising software architecture — the reference website for the C4 model.
C4 Model at Wikipedia — A good starting point guide for how the C4 model works.
Modeling Software Architecture With C4 — A step by step model builder’s guide to C4.
A Crash Course in C4 Modelling — A useful beginner’s guide to C4 modelling using a simple URL shortening web site as an example.
C4 Model: Describing Software Architecture — A more detailed presentation of the C4 model. Interestingly, the author describes the Class Diagrams (Code) as “Details on demand” implying that these details inherent in the C4 model aren’t always necessary for architecture, a point that I agree strongly with.
Domain Driven Design: Everything You Always Wanted to Know About it, But Were Afraid to Ask — a useful introduction to the nuts and bolts of domain driven design, without linking directly to Domain Modelling or the C4 model.