Reexamining C4 vs 4+1: Practical Insights into Architecture View Modeling

1. Relationship between C4 and the 4+1 View Model

Kruchten’s 4+1 model (1995) defines four main views—Logical, Process, Development, Physical—and a Scenarios view. The author asks which C4 layers (System Context, Container, Component, Code) correspond to these views. The answer is not a one‑to‑one mapping: the C4 Container layer mixes logical boundaries, runtime topology, and deployment units, making it a hybrid that aligns with multiple 4+1 views.

Thus, 4+1 separates concerns by "view dimension" while C4 separates by "granularity level"; the two are orthogonal. Modern practices (DDD bounded contexts, Clean/Hexagonal Architecture, micro‑services) already blur the traditional separation, favoring C4’s granularity‑driven approach.

2. Scaling Beyond Elements – Relationships Also Grow

The official C4 definition of "zoom‑in" focuses on elements (e.g., a System box → Container box → Component box). The author argues that relationships should be refined together with elements. For example, a Context‑level relationship "Order System → Payment System: send payment request" becomes at the Container level "Order API → Payment System: POST /payments with JWT" and at the Component level "PaymentGatewayAdapter → Payment System: call POST /payments". This explicit refinement creates a cross‑layer consistency checklist used in architecture reviews.

3. Layered Zoom‑In for Dynamic (Runtime) Views

C4’s Dynamic Diagram already supports elements at any granularity. Using an e‑commerce order flow, the author shows a Container‑level dynamic diagram that captures service orchestration, and a Component‑level diagram that details internal interactions within the Payment Service. The two diagrams serve different audiences (architects vs. developers) while preserving element and relationship consistency.

4. Layered Zoom‑In for Deployment Views

The official C4 Deployment Diagram is flat, using nested deployment nodes but without explicit ties to the four C4 layers. The author proposes a layered deployment view where each C4 abstraction has a corresponding deployment diagram that reuses the same elements:

System‑level deployment : overall cloud placement, multi‑AZ high‑availability, CDN exposure (audience: infrastructure architects).

Container‑level deployment : Kubernetes Deployments, replica counts, Service Mesh routing, database replication (audience: developers and SREs).

Component‑level deployment : Pod side‑cars for logging, tracing, hot‑config, thread‑pool isolation inside the Payment Service (audience: developers and performance engineers).

Two governing principles are enforced:

Element consistency : deployment diagrams must only use elements defined in the corresponding structural view.

Relationship mapping : deployment relationships either inherit structural relationships or explicitly declare deployment‑only links (e.g., DB master‑slave replication).

This eliminates the mapping gap between structural and deployment diagrams, but it increases documentation entropy. The author stresses that the approach is viable only when backed by "Architecture as Code" tools that generate and validate all views automatically.

5. Summary

C4’s strength lies in its minimalism and engineering focus. When systems become complex, teams need to extend C4 with practices such as refining relationships, applying layered zoom‑in to dynamic and deployment views, and ensuring orthogonal alignment with 4+1’s view dimensions. These extensions are not part of the official C4 specification but stem from real‑world experience and may not suit every team.