C4 est un modèle permettant d’illustrer une architecture logicielle à différents niveaux : contextuel, conteneurs, composants et code. À chaque niveau correspondent différentes abstractions et différents publics.
Un diagramme de contexte C4 représente le système logiciel et la façon dont il s’inscrit dans son environnement vis-à-vis de ses utilisateurs et des autres systèmes logiciels qui interagissent avec lui.
Quel que soit la façon de représenter les utilisateurs (acteurs,
clients, rôles, personnes, etc), ceux sont les différents humains
qui utilisent le système.
Un système logiciel est le plus haut niveau d’abstraction et décrit quelque chose qui fournit une valeur à ses utilisateurs., qu’ils soient humains ou non. Ceci inclut le système modélisé et tout autre système dont celui-ci dépend (et vice-versa).
A System Context diagram is a good starting point for diagramming and documenting a software system, allowing you to step back and see the big picture. Draw a diagram showing your system as a box in the centre, surrounded by its users and the other systems that it interacts with.
Detail isn’t important here as this is your zoomed out view showing a big picture of the system landscape. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details. It’s the sort of diagram that you could show to non-technical people.
Un diagramme des conteneurs C4 détaille les conteneurs (applications, bases de données, microservices, etc) qui constituent le système logiciel. Les choix technologiques sont un élément-clé de ce diagramme.
A container represents something that hosts code or data. 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:
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.
Once you understand how your system fits in to the overall IT environment, a really useful next step is to zoom-in to the system boundary with a Container diagram. A “container” is something like a server-side web application, single-page application, desktop application, mobile app, database schema, file system, etc. Essentially, a container is a separately runnable/deployable unit (e.g. a separate process space) that executes code or stores data.
The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It’s a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike.
NB : This diagram says nothing about deployment scenarios, clustering, replication, failover, etc.
Un diagramme des composants C4 détaille le contenu d’un conteneur pour en dévoiler les composants. Ces composants doivent correspondre à des abstractions réelles (ensemble de code).
The word “component” is a hugely overloaded term in the software development industry, but in this context a component is simply 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.
Next you 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.
Pour finir, si nécessaire, il est possible de détailler individuellement chaque composant pour décrire son implémetation (diagramme de classe UML par exemple).
This is an optional level of detail and is often available on-demand from tooling such as IDEs. Ideally this diagram would be automatically generated using tooling (e.g. an IDE or UML modelling tool), and you should consider showing only those attributes and methods that allow you to tell the story that you want to tell. This level of detail is not recommended for anything but the most important or complex components.
The C4 model provides a static view of a single software system but, in the real-world, software systems never live in isolation. For this reason, and particularly if you are responsible for a collection of software systems, it’s often useful to understand how all of these software systems fit together within the bounds of an enterprise. To do this, simply add another diagram that sits “on top” of the C4 diagrams, to show the system landscape from an IT perspective. Like the System Context diagram, this diagram can show the organisational boundary, internal/external users and internal/external systems.
Essentially this is a high-level map of the software systems at the enterprise level, with a C4 drill-down for each software system of interest. From a practical perspective, a system landscape diagram is really just a system context diagram without a specific focus on a particular software system.
A simple dynamic diagram can be useful when you want to show how elements in a static model collaborate at runtime to implement a user story, use case, feature, etc. This dynamic diagram is based upon a UML communication diagram (previously known as a “UML collaboration diagram”). It is similar to a UML sequence diagram although it allows a free-form arrangement of diagram elements with numbered interactions to indicate ordering.
A deployment diagram allows you to illustrate how containers in the static model are mapped to infrastructure. This deployment diagram is based upon a UML deployment diagram, although simplified slightly to show the mapping between containers and deployment nodes. A deployment node is something like physical infrastructure (e.g. a physical server or device), virtualised infrastructure (e.g. IaaS, PaaS, a virtual machine), containerised infrastructure (e.g. a Docker container), an execution environment (e.g. a database server, Java EE web/application server, Microsoft IIS), etc. Deployment nodes can be nested.
|Localisation (interne ou externe)|
|Localisation (interne ou externe)|
|The set of containers that make up the software system|
|Conteneur||Un système logiciel||Nom[fn:1]|
|The set of components within the container|
|The set of code elements (e.g. classes, interfaces, etc) that the component is implemented by|
|Élément de code||Un composant||Nom[fn:1]|
|Fully qualified type|
[fn:1] All elements in the model must have a name, and that name must be unique within the parent context.
[fn:2] Relationships are permitted between any elements in the model, in either direction.
Last edited by Olm, 2020-03-02 15:41:16