C4 Model v1.0 Metamodel
Note: some parts of the below text are quoted from c4model.com to maintain the accuracy and correctness of the information. If you want to learn about the C4 model from its original source, please go to c4model.com. Some parts of the material on this page are different from the original text to adjust the terminology, concepts, and instrumentation with Archipeg.
Synopsis: 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, threat modelling, etc.
Tip: watch a video tutorial about C4 model in Archipeg.
Idea Behind C4 Model
C4 model helps describe enterprise and solution architecture at various levels, starting from software systems and integrations down to code modules grouping cohesive pieces of your software.
In Archipeg, using the C4 model, you can describe the three levels of the structure - Context, Containers, and Components. The first three levels are sufficient to cover aspects relevant to Enterprise Architecture, Solution Architecture, and partly Application Architecture, thus allowing to describe, analyze, or explain most architectures. The fourth element, Code, is an optional level of detail as explained in the original source of the C4 model, and it is not currently ported to Archipeg.
In addition to the three "C," our port of C4 model also describs supplementary levels of detail - system landscape and deployments.
C4 Model Diagram
Below is a diagram representing the entire C4 model port in Archipeg. Please click on the picture to open it in a new window and examine the details.
How to Read the Diagram
The diagram above is split into three parts, in each section highlighting the primary participants and displaying the supporting participants. Note that the diagram can show a concept multiple times, once as a primary participant in the area where it originates and then again in sections where it plays a supporting role.
Meaning of Two-Way Arrows
As you can see, some arrows have two-way endings with two different labels. This annotation is shorthand for showing two separate arrows, which means in Archipeg, these elements correspond to two independent associations. e.g., in the "Level 3: Component" section, Component and Software System are connected with a two-way arrow. Thus, you can use one association to denote that the Component accesses a Software System (the component is the initiator), or the other association if the Software System accesses a Component (Software System is the initiator). The same kind of association exists between a Container and a Software System under the "Level 2: Container" section, but in this case, both arrows are shown separately.
C4 Model Abstractions with Archipeg
C4 model comes with abstractions, all of which are available in Archipeg as object types. Please scroll down to the metamodel details with each object type description to learn more.
C4 Model Diagrams with Archipeg
The C4 model describes layers of diagrams, and you can create those diagrams in Archipeg if you use the proper object types that come with a project that has the C4 model selected as a metamodel. Below we will outline object types that support the creation of C4 model diagrams using Archipeg.
Level 1: System Context Diagram
Use object types: Person, Software System.
Level 2: Container Diagram
Use object types: Container, Technology, Deployment Node, Infrastructure Node.
Supporting object types: Person, Software System.
Level 3: Component Diagram
Use object types: Component, Technology Concept
Supporting object types: Person, Software System, Container, Technology (to specify the origin of a technology concept).
Level 4: Code
At the moment, you cannot create Code diagrams in Archipeg. Either way, this level of diagramming is optional, according to the C4 model official website.
Supplementaly Level: System Landscape Diagram
Use object types: Person, Software System.
Supplementary Level: Dynamic Diagram
At the moment, you cannot create dynamic diagrams in Archipeg.
Supplementary Level: Deployment Diagram
Use object types: Container, Deployment Node, Infrastructure Node.
C4 Model v1.0 Metamodel Detailed Description
Objects
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.
Person
A person represents one of the human users of your software system (e.g. actors, roles, personas, etc).
Container
A container is 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.
Technology
Technology is a framework, library, or runtime that supports implementing, building, hosting, or instantiating a container. e.g., DB technology (such as MS SQL or Oracle) or application framework (such as .NET Core or Spring Boot).
Deployment Node
A deployment node is something like physical infrastructure (e.g. a physical server or device), virtualized infrastructure (e.g. IaaS, PaaS, a virtual machine), containerized 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.
Infrastructure Node
Infrastructure node is a separately hosted or instantiated technology or runtime invoked or accessed from a container to perform its functions. e.g. DNS services, load balancers, firewalls, etc. Infrastructure nodes can be nested.
Component
Component is a grouping of related functionality encapsulated behind a well-defined interface. In a programming language - collection of implementation classes behind an interface or a module. Typically, not correlated with JAR file, DLL, shared library, etc. All components inside a container typically execute in the same process space. Components are not separately deployable units.
Technology Concept
Concept within a specific technology (such as Spring Boot or Angular) that a component can implement. e.g. Spring Boot Controller, Angular Service, etc.
Associations
Person::Uses Software Systems <-> Software System::Is Used by Persons
Outgoing: Software Systems that this Person uses (initiated by the Person).
Incoming: Persons using this Software System (initiated by the Person).
Software System::Serves Persons <-> Person::Is Served by Software Systems
Outgoing: Persons that this Software System serves (initiated by the Software System).
Incoming: Software Systems that serve this Person (initiated by the Software System).
Software System::Accesses Software Systems <-> Software System::Is Accessed by Software Systems
Outgoing: Software Systems that this Software System accesses.
Incoming: Software Systems that access this Software System.
Person::Interacts with Persons <-> Person::Is Interacted by Persons
Outgoing: Persons with whom this Person interacts.
Incoming: Persons who interact with this Person.
Software System::Consists of Containers <-> Container::Belongs to Software System
Outgoing: Containers that are part of this Software System; i.e., this Software System decomposes into Containers.
Incoming: Software System that consists of this and (possibly) other Containers.
Software System::Accesses Containers <-> Container::Is Accessed by Software Systems
Outgoing: Containers that this Software System accesses (initiated by the Software System).
Incoming: Software Systems that access this Container (initiated by the Software System).
Container::Accesses Software Systems <-> Software System::Is Accessed by Containers
Outgoing: Software Systems that this Container accesses (initiated by the Container).
Incoming: Containers that access this Software System (initiated by the Container).
Person::Uses Containers <-> Container::Is Used by Persons
Outgoing: Containers that this Person uses (initiated by the Person).
Incoming: Persons using this Container (initiated by the Person).
Container::Serves Persons <-> Person::Is Served by Containers
Outgoing: Persons that this Container serves (initiated by the Container).
Incoming: Containers that serve this Person (initiated by the Container).
Container::Accesses Containers <-> Container::Is Accessed by Containers
Outgoing: Containers that this Container accesses.
Incoming: Containers that access this Container.
Container::Uses Technologies <-> Technology::Is Used by Containers
Outgoing: Technologies that this Container uses (such as MS SQL, Oracle, .NET Core, or Spring Boot).
Incoming: Containers using this Technology.
Deployment Node::Child Nodes <-> Deployment Node::Parent Nodes
Outgoing: Child Nodes of this Deployment Node (i.e., Deployment Nodes are nested).
Incoming: Parent Deployment Nodes that consist of this and (possibly) other child Nodes. Multiple parents are allowed since this element represents a logical concept rather than a physical one.
Container::Is Deployed to Nodes <-> Deployment Node::Hosts Containers
Outgoing: Deployment Nodes onto which this Container is deployed.
Incoming: Containers that are deployed and hosted on this Deployment Node.
Infrastructure Node::Child Nodes <-> Infrastructure Node::Parent Nodes
Outgoing: Child Nodes of this Infrastructure Node (i.e., Infrastructure Nodes are nested).
Incoming: Parent Infrastructure Nodes that consists of this and (possibly) other child Nodes. Multiple parents are allowed since this element represents a logical concept rather than a physical one.
Container::Uses Infrastructure Nodes <-> Infrastructure Node::Is Used by Containers
Outgoing: Infrastructure Nodes that this Container uses (such as DNS services, load balancers, or firewalls).
Incoming: Containers using this Infrastructure Node.
Container::Consists of Components <-> Component::Belongs to Container
Outgoing: Components that are part of this Container; i.e., this Container decomposes into Components.
Incoming: Container that consists of this and (possibly) other Components.
Software System::Accesses Components <-> Component::Is Accessed by Software Systems
Outgoing: Components that this Software System accesses (initiated by the Software System).
Incoming: Software Systems that access this Component (initiated by the Software System).
Component::Accesses Software Systems <-> Software System::Is Accessed by Components
Outgoing: Software Systems that this Component accesses (initiated by the Component).
Incoming: Components that access this Software System (initiated by the Component).
Person::Uses Components <-> Component::Is Used by Persons
Outgoing: Components that this Person uses (initiated by the Person).
Incoming: Persons using this Component (initiated by the Person).
Component::Serves Persons <-> Person::Is Served by Components
Outgoing: Persons that this Component serves (initiated by the Component).
Incoming: Components that serve this Person (initiated by the Component).
Container::Accesses Components <-> Component::Is Accessed by Containers
Outgoing: Components that this Container accesses (initiated by the Container).
Incoming: Containers that access this Component (initiated by the Container).
Component::Accesses Containers <-> Container::Is Accessed by Components
Outgoing: Containers that this Component accesses (initiated by the Component).
Incoming: Components that access this Container (initiated by the Component).
Technology::Concepts <-> Technology Concept::Originates from Technology
Outgoing: Concepts in this Technology (e.g., Angular Service is a Concept of Angular Technology).
Incoming: Technology where this Concept originates (e.g., Angular Service is a Concept of Angular Technology).
Component::Accesses Components <-> Component::Is Accessed by Components
Outgoing: Components that this Component accesses.
Incoming: Components that access this Component.
Component::Implements Technology Concepts <-> Technology Concept::Is Implemented by Components
Outgoing: Technology Concepts that this Component implements (e.g., Spring Boot Controller or Angular Service).
Incoming: Components that implement this Technology Concept.
See Also