Diagrams

Diagrams let you model how components relate to each other, and what kind of data is transmitted between them.

Diagram Levels

Diagrams can exist at the following levels: C1 , C2 , C3 , C4 , L , D , and P .

Levels C1 to C4 are directly inspired by the C4 model.

  • C1 (System Context Diagram)

    Describes concrete systems within a context and what kind of data flows between them.

  • C2 (Container Diagram)

    Describes a subsystem of a system or relations in the C1 diagram and focuses on more concrete components used to implement the system. Databases, micro services, cloud components, and what data that is moved between them is typically described here.

  • C3 (Component Diagram)

    Describes the implementation of a component shown in the C2 diagram and technical details on how it's implemented.


Levels L and D are also based on the C4 model and the support diagram types described there.

  • L (Landscape Diagram)

    A high-level diagram, not scoped to a context, like the C1 diagram typically is. Describes all concrete systems and the data that is transferred between them.

    Useful in smaller architectures where it's possible to fit all systems in one diagram.

  • D (Deployment Diagram)

    Shows concrete details on how a C2 or C3 is deployed. Deployment details are typically details that should be modeled separately from the more abstract architecture as it might vary in different scenarios - a solution might be deployed on test, in production, or in different customer environments, for example.

Tools

What the tools are used to model very much depends on what level of diagram we're currently using.

  • Components

    In higher-level diagrams such as L and C1 , a component is a concrete system; in lower-level diagrams, components are usually concrete components such as databases, services, API endpoints, etc.

  • Containers

    Containers are used to model boundaries in our architecture. In higher-level diagrams, these are typically used to describe environments, such as on-premise and cloud environments.

    In lower-level diagrams, they are used to describe things such as network boundaries, etc. A container containing a component models that the component belongs to that container.

  • Relations

    Relations are used to model how components depend on each other and what data is sent between them. These are directional; a relation that goes from one component to another models that the first component initiates communication with the second component.

State and Lifecycle

Diagrams can have one of three states: Draft , Active , and Archived . These states can be changed freely at any time.

A diagram starts as a draft. Draft diagrams can use draft components and can only be linked to from components and relations in other draft diagrams. Basically, a draft diagram isn't considered a part of your architectural model yet. Use drafts to sketch out ideas and test things without polluting the model.

An active diagram is part of your model, can use any active component, and link to any active diagram. Active diagrams cannot use draft components.

Archived diagrams can no longer be used or edited. Existing links remain, but new ones cannot be created.

ℹ️ We recommend you archive active diagrams before deleting them. Doing so will hide them when diagramming, not affect existing uses, and not make it a permanent decision quite yet.

When you do decide to delete a diagram, Revision will inform you if—and if so, where—it still is used, to help you make sure you are not changing your model in an unexpected way.