C4 Modeling is a technique (more of a [[Pattern]]) for documenting the architecture of a _code_ solution. It's a 4-layer [[Decomposition Understanding|decomposition]] of an IT solution. The technique doesn't prescribe particular [[Ontology, Semantics, and Syntax|syntax]]/notation, instead it allows you to BYO language/tooling. Borrowing [[UML]] syntax is common, although not required. You could also use [[Archimate]] - see [here](https://www.archimatetool.com/blog/2020/04/18/c4-model-architecture-viewpoint-and-archi-4-7/). The concept & [official website](https://c4model.com) were made by a guy named [Simon Brown](https://simonbrown.je). I am working on a [[C4 Model of the PDW]]. ![[IMG_1253.png]] # Layers Each of these layers drills (or "double-clicks") into the layer below it. 1. **Context** - where the system sits in relation to its environment, including its users (a la [[Use Case Diagrams]]) and the other systems it interacts with. Here your system is a [[Black Box]]. This is equivalent to the "A-0" diagram in [[IDEF0]]. 2. **Containers** - the high-level shape of the software, and what parts of the shape have what responsibilities. It shows what components there are, and how they communicate with one another inside your system. This is the last level of diagramming that's intended for external audiences. All subsequent diagrams are for the implementation team, _optional_, and **should only be created if they add value**. This is closest to a [[Block Definition Diagram]] from [[SysML]]. 3. **Components** - this drills down into _each_ of the containers identified in the container diagram **as deemed useful**. You do not necessarily need to create component diagrams for every container. You may not even need to create _any_. It depends on what's deemed value-add. **This level of diagram stops being useful to people outside the implementation team.** This is equivalent to an [[Internal Block Diagram]]. 4. **Code** - again, only on an as-needed basis you can create diagrams using [[Entity-Relationship Diagrams]], [[UML]] [[Class Diagrams]], or other representations to show the transition between conceptual system components and their actual _implementation_. # Principles The C4 Modeling approach is very pragmatic. I dig it. The principles are codified into a [[Checklists|checklist]] available [here](https://c4model.com/review). In essence the principles all amount to saying **Diagrams should be self-explanatory**, not requiring pre-existing knowledge or understanding of conventions. To achieve this - use descriptive labels on everything, don't overload arrows to mean many things, use legends, etc. **** ## Source - https://en.wikipedia.org/wiki/C4_model - [https://c4model.com](https://c4model.com/) - https://www.archimatetool.com/blog/2020/04/18/c4-model-architecture-viewpoint-and-archi-4-7/ ## Related - [[Diagram Types (index)]]