Skip to content

Latest commit

 

History

History
60 lines (42 loc) · 6.1 KB

C4 model.md

File metadata and controls

60 lines (42 loc) · 6.1 KB

C4 model is a lean graphical notation technique for modelling the architecture of software systems

C4 model

  • C4 model documents the architecture of a software system, by showing multiple points of view that explain the decomposition of a system into containers and components, the relationship between these elements, and, where appropriate, the relation with its users.

The viewpoints are organized according to their hierarchical level:

  • Context diagrams (level 1): show the system in scope and its relationship with users and other systems;
  • Container diagrams (level 2): decompose a system into interrelated containers. A container represents an application or a data store;
  • Component diagrams (level 3): decompose containers into interrelated components, and relate the components to other containers or other systems;
  • Code diagrams (level 4): provide additional details about the design of the architectural elements that can be mapped to code. C4 model relies at this level on existing notations such as Unified Modelling Language (UML), Entity Relation Diagrams (ERD) or diagrams generated by Integrated Development Environments (IDE).

Level 1: A System Context diagram provides a starting point, showing how the software system in scope fits into the world around it. Level 1 Level 2: A Container diagram zooms into the software system in scope, showing the high-level technical building blocks. Level 2 Level 3: A Component diagram zooms into an individual container, showing the components inside it. Level 3 Level 4: A code (e.g. UML class) diagram can be used to zoom into an individual component, showing how that component is implemented. Level 4

c4-overview

abstractions

Person

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

Software System

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.

Container (applications and data stores)

Not Docker! In the C4 model, 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. In real terms, a container is something like:

  • Server-side web application: A Java EE web application running on Apache Tomcat, an ASP.NET MVC application running on Microsoft IIS, a Ruby on Rails application running on WEBrick, a Node.js application, etc.
  • Client-side web application: A JavaScript application running in a web browser using Angular, Backbone.JS, jQuery, etc.
  • Client-side desktop application: A Windows desktop application written using WPF, an OS X desktop application written using Objective-C, a cross-platform desktop application written using JavaFX, etc.
  • Mobile app: An Apple iOS app, an Android app, a Microsoft Windows Phone app, etc.
  • Server-side console application: A standalone (e.g. "public static void main") application, a batch process, etc.
  • Serverless function: A single serverless function (e.g. Amazon Lambda, Azure Function, etc).
  • Database: A schema or database in a relational database management system, document store, graph database, etc such as MySQL, Microsoft SQL Server, Oracle Database, MongoDB, Riak, Cassandra, Neo4j, etc.
  • Blob or content store: A blob store (e.g. Amazon S3, Microsoft Azure Blob Storage, etc) or content delivery network (e.g. Akamai, Amazon CloudFront, etc).
  • File system: A full local file system or a portion of a larger networked file system (e.g. SAN, NAS, etc).
  • Shell script: A single shell script written in Bash, 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.

Component

The word "component" is a hugely overloaded term in the software development industry, but in this context a component is a grouping of related functionality encapsulated behind a well-defined interface. If you're using a language like Java or C#, the simplest way to think of a component is that it's a collection of implementation classes behind an 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.

An important point to note here is that all components inside a container typically execute in the same process space. In the C4 model, components are not separately deployable units.

Uses / Summary

C4 model facilitates collaborative visual architecting and evolutionary architecture in the context of agile teams where more formal documentation methods and up-front architectural design are not desired. The C4 model is an 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 (e.g. STRIDE/LINDDUN), etc.

Although primarily aimed at software architects and developers, the C4 model provides a way for software development teams to efficiently and effectively communicate their software architecture, at different levels of detail, telling different stories to different types of audience, when doing up front design or retrospectively documenting an existing codebase.