C4 Modelling

What

• "abstraction-first" approach to diagramming software architecture

• The C4 model is...

  1. A set of hierarchical abstractions (software systems, containers, components, and code).

  2. A set of hierarchical diagrams (system context, containers, components, and code).

  3. Notation independent.

  4. Tooling independent.

Why

• easy to learn

• developer friendly approach to software architecture diagramming.

• Good software architecture diagrams assist with communication inside/outside of software development/product teams,

• efficient onboarding of new staff

• architecture reviews/evaluations

• risk identification (e.g. risk-storming)

• threat modelling,

Structure

• LEvels

  • Level 1: A System Context diagram provides a starting point, showing how the software system in scope fits into the world around it.

  • Level 2: A Container diagram zooms into the software system in scope, showing the high-level technical building blocks.

  • Level 3: A Component diagram zooms into an individual container, showing the components inside it.

  • Level 4: A code (e.g. UML class) diagram can be used to zoom into an individual component, showing how that component is implemented.

• you don't need to use all 4 levels of diagram; only those that add value - the System Context and Container diagrams are sufficient for many software development teams.

• need a common set of abstractions to create a ubiquitous language that we can use to describe the static structure of a software system

  • A software system is made up of one or more containers (applications and data stores), each of which contains one or more components, which in turn are implemented by one or more code elements (classes, interfaces, objects, functions, etc). And people may use the software systems that we build.

  • A person represents one of the human users of your software system (e.g. actors, roles, personas, etc).

  • A software system is the highest level of abstraction and describes something that delivers value to its users, whether they are human or not. This includes the software system you are modelling, and the other software systems upon which your software system depends (or vice versa). In many cases, a software system is "owned by" a single software development team.

  • a container represents an application or a data store. A container is something that needs to be running in order for the overall software system to work.

    • ie Server-side web application, Client-side web application, Client-side desktop application, Mobile app, Server-side console application, Database, Blob or content store, file system etc

    • A container is essentially a context or boundary inside which some code is executed or some data is stored. And each container is a separately deployable/runnable thing or runtime environment, typically (but not always) running in its own process space. Because of this, communication between containers typically takes the form of an inter-process communication.

  • a component is a grouping of related functionality encapsulated behind a well-defined interface.

    • Aspects such as how those components are packaged (e.g. one component vs many components per JAR file, DLL, shared library, etc) is a separate and orthogonal concern.

    • all components inside a container typically execute in the same process space

    • not separately deployable units

Links

• https://c4model.com/

• https://youtu.be/36OTe7LNd6M The lost art of software design by Simon Brown

• https://mattjhayes.com/2020/05/10/diagrams-with-c4-model/