Beyond Static Structure: C4's Dynamic, Deployment & Landscape Diagrams

Introduction

The previous articles covered C4's four core static structure diagrams: System Context, Container, Component, and Code diagrams. These describe a software system's static structure at four abstraction levels. However, software is not static—it must run to deliver value. Therefore, three supplementary diagrams are needed: Dynamic Diagrams to describe how a single feature works at runtime, Deployment Diagrams to show how software systems and containers are deployed onto infrastructure, and System Landscape Diagrams to visualize how multiple software systems fit together across an organization.

2. Dynamic Diagram

2.1 Key Attributes

Intent. Static structure diagrams show all static elements and relationships. A specific feature at runtime uses only a subset of those elements. The Dynamic Diagram's intent is to show only the elements participating in that feature's delivery, explaining how the feature works at runtime.

Scope. The scope depends on the story you want to tell. At the highest abstraction level, you can show multiple software systems collaborating to deliver a business capability; at the lowest, you can show code elements inside a component interacting to fulfill a function. As with static diagrams, the author recommends narrowing the scope—resist the urge to show components across multiple containers, especially when those containers belong to different software systems.

Content. Dynamic diagrams depict elements—or more precisely, element instances—interacting at runtime. UML sequence diagrams and collaboration diagrams (communication diagrams in UML 2.x) are well suited for this.

Why useful? Static structure diagrams provide good summaries of elements at each abstraction level, but they cannot conveniently show how a single feature works independently. That is precisely the Dynamic Diagram's role.

Who needs to see? Aligns with the audience of the corresponding static diagram: system-level collaborations for technical and non-technical stakeholders (like System Context), container collaborations for architects and engineers (like Container diagram), component collaborations for architects and engineers (like Component diagram), and code-element collaborations for engineers (like Code diagram).

Recommended? Yes, but sparingly. If a system provides a hundred features, drawing a Dynamic Diagram for each yields low value—the effort to create and maintain them is huge. Use Dynamic Diagrams only for interesting, recurring patterns or for features with extremely complex interactions that cannot be explained in text.

2.2 Two Drawing Styles

Sequence Diagram. Shows several element instances interacting: instances arranged left to right, time axis extending top to bottom. Horizontal arrows represent collaboration—messages, requests, etc. The vertical order of arrows indicates interaction sequence from start to finish.

UML sequence diagrams typically show class (object) instances collaborating at runtime, but nothing prevents you from showing instances of people, software systems, containers, or components. If you are familiar with UML sequence diagrams, you may use guard conditions, loops, and lifeline events to add precision—use them whenever they add value.

Collaboration Diagram. An alternative way to show behavior, called a communication diagram in UML 2.x. It conveys exactly the same information as a sequence diagram but uses a simpler box-and-arrow style with free layout, and numbers the connectors to indicate interaction order.

Both diagrams express the same information; choose whichever you prefer.

2.3 Example: Online Banking Login

The example uses the same online banking system, focusing on the login feature at the backend container's component level. Both sequence and collaboration styles depict the same flow:

UI container submits user credentials to the backend's Sign-in API component via a single API request.

Sign-in API component calls the Security component to validate credentials.

Security component retrieves the user's account information from the Database container .

Database returns the requested information.

Security component validates credentials; on success, issues a session token to the Sign-in API component.

Sign-in API component returns the session token to the UI.

The collaboration-style version reuses a subset of boxes and arrows from the earlier example component diagram to illustrate the login flow.

3. Deployment Diagram

3.1 Key Attributes

Intent. Deployment diagrams show how instances of software systems and containers from the static model are deployed onto infrastructure in a specific deployment environment (e.g., development, test, staging, production).

Scope. Generally, limit a single deployment diagram to one software system—showing how that system is deployed into one environment. If you own multiple systems deployed on the same infrastructure, you may relax this principle to show them sharing that infrastructure.

Content. C4's deployment diagram is loosely based on UML deployment diagrams and includes: container instances, software system instances, deployment nodes, infrastructure nodes .

Container instances: Primary purpose is to show how your applications and data stores (C4 containers) are deployed into an environment. Example: a Java application deployed onto an on-premise server, or into a Docker container running in a cloud environment.

Software system instances: Just as you may model an external dependency as a software system, you may want to model its concrete instance in a deployment environment.

Deployment nodes: Represent a piece of infrastructure you deploy software into—the location where software systems or container instances run. Examples: physical infrastructure, virtualized infrastructure, containerized infrastructure, a server environment. Deployment nodes can nest to express infrastructure hierarchy.

Infrastructure nodes: Represent facilities or services used in the environment, such as DNS services, routers, load balancers, firewalls.

Why useful? Container diagrams usually reflect only one deployment environment (production), but most systems are simultaneously deployed in multiple different environments (dev, test, staging, prod). During development, a Java app might run in a local JVM on a laptop; in production, the same app is built as a Docker image and deployed to AWS. Putting both environments on one diagram causes confusion. Deployment diagrams answer how the system's applications and data stores are deployed into a specific environment.

Who needs to see? Similar to container diagrams: software architects and engineers who build and maintain the software, plus operations and support staff.

Recommended? Yes, recommended for all software engineering teams. Especially valuable for documenting production environments—the most critical deployment environment—so information is instantly available during operational incidents.

3.2 Examples: Development and Production Environments

Development Environment

The outermost box is a deployment node representing the bank's wide area network—all development occurs inside the bank network. Inside is a deployment node representing a developer's laptop .

The story starts with the backend —a Java/Spring Boot application providing a JSON/HTTP Web API to the UI. It must communicate with the database, statement store, and two external software systems. During development, the backend runs on the developer's laptop in a locally installed JVM for easy start/stop, log access, and attaching profilers/debuggers.

To simplify UI development, the UI runs in a locally installed browser . Communication between UI and backend uses simple HTTP requests via local addresses like http://localhost:8080, avoiding the hassle of configuring local TLS certificates.

The UI needs a browser-accessible location to load from. In development, a local nginx server hosts static content, run via Docker rather than installed directly on the laptop.

The database follows the same approach: MySQL runs in Docker instead of a local install.

The statement store is an object store—specifically AWS S3 . The backend communicates via the AWS S3 API in the AWS Java SDK. Two main configuration options exist:

Create a real AWS S3 bucket in the cloud.

Run a local service that mimics the AWS S3 API .

The first option has drawbacks: hosting costs, requires internet connectivity, and risks data leakage if misconfigured. The team chooses the second option, using MinIO , also run via Docker.

The backend also integrates with Amazon Simple Email Service (SES) and the Core Banking System . Ideally both run in the development environment for integration testing. For Amazon SES, the team chooses a local SES-compatible service to avoid sending emails to the external world and risking data leakage.

Finally, a development instance of the Core Banking System is needed. The Core Banking team provides a dev instance running on a server named corebanking-dev in the bank's data center.

Key point: The diagram uses the abstract concept of a software system instance. The diagram shows a Core Banking System instance running on corebanking-dev, but the reality may differ. From the internet banking team's perspective, the Core Banking System is a software system dependency treated as an opaque black box . They don't need to understand its internal complexity—just point the backend instance at corebanking-dev to make API calls.

The development environment legend is nearly identical to the example container diagram's legend, with the addition of a deployment node shape.

Production Environment

The production deployment is inevitably more complex, but the same principles apply: most software runs in the AWS cloud environment , except the UI and Core Banking System .

Summary of the production diagram:

UI runs outside our infrastructure , in customers' browsers .

Customers access https://ib.bigbank.com to load the UI. ib.bigbank.com is a Cloudflare DNS CNAME aliasing an AWS S3 bucket holding static content. The CNAME is configured to proxy through Cloudflare , leveraging its static content caching to reduce traffic to the S3 bucket , improving performance and reducing cost.

UI makes API calls via https://ib-api.bigbank.com, another Cloudflare-managed DNS CNAME aliasing an AWS Application Load Balancer that forwards traffic to the backend. These requests are not proxied because they cannot be cached.

Backend is packaged as a Docker image and runs via AWS Fargate , providing a convenient way to run Docker images without managing servers. The Docker image is pushed to a Docker registry (e.g., private Amazon Elastic Container Registry ), omitted from the diagram for simplicity.

Database is managed via Amazon Relational Database Service (RDS) , handling underlying infrastructure provisioning.

Statement store's S3 bucket uses the real AWS S3 service .

Similarly, the real Amazon Simple Email Service runs in the same AWS region , depicted as a software system instance.

Production Core Banking System runs on a server named corebanking-live in the bank data center, connected via AWS Direct Connect to establish a secure, high-speed private network between AWS infrastructure and the data center.

Compared to the development diagram, many protocols are now HTTPS instead of HTTP , reflecting production's higher security requirements.

All components run in AWS eu-west-1 region , but the author deliberately omitted specific availability zones for simplicity. Adding AZs, subnets, and network zones to your own deployment diagrams is perfectly fine.

The production legend resembles the development legend, adding an infrastructure node shape, a thick solid arrow for the private network connection, and dashed-bordered boxes to mark independent organizational boundaries .

4. System Landscape Diagram

4.1 Key Attributes

Intent. System Landscape Diagrams help answer: (1) How do the various software systems in a team/department/organization fit together? (2) What is the impact if a software system changes or is removed? (3) What is the impact if we reorganize, merge, or split the organization?

Scope. Scope is up to you. Common choices: all software systems within an organization, a team or department, a product domain, a business capability, or a DDD bounded context.

Content. Practically, a System Landscape Diagram is a System Context Diagram without focus on a specific software system . It shows people and software systems relevant to a given scope. It typically contains only two element types: people and software systems .

Why useful? Enterprise architecture concerns more than software systems, but many organizations lack a top-down holistic view of their IT landscape. Drawing the landscape from a software system perspective provides a way to think beyond the typical silos formed around IT systems and the teams responsible for them.

Who needs to see? Same as System Context Diagram: technical and non-technical stakeholders, inside and outside the software team.

Recommended? Yes, especially for larger organizations. The System Landscape Diagram is a bridge to the enterprise architecture world. Large organizations find it useful because it maps the software systems existing across all or part of the organization. Making it interactive—e.g., double-click a software system to jump to its C4 model diagrams—yields an interactive system landscape map .

4.2 Example

When drawing a System Context Diagram, you typically include only people and software systems directly related to the system in focus. In contrast, a System Landscape Diagram paints a wider view telling a broader story .

The starting point is a partial System Landscape Diagram for the fictional bank. Its content matches the Internet Banking System Context Diagram seen earlier.

Next, the map expands to a wider landscape .

Additional elements include the ATM software system , and the bank's internal customer service staff and back-office staff , all related to the Core Banking System . The relationship between personal banking customers and customer service staff is deliberately shown because it clarifies why customer service staff need the Core Banking System.

The accompanying legend uses the same visual style as the System Context Diagram because both display the same element types (people and software systems).

A further revised example adds two dashed-bordered boxes representing the organizational boundaries of Big Bank and Amazon Web Services . This highlights which software systems and people fall inside the bank's boundary and which lie outside.

1. The C4 Model for Visualising Software Architecture Chapters 7, 8, 9