Misuses and Mistakes of the C4 model

I recently watched Simon Brown's presentation at GOTO 2024 on "The C4 Model – Misconceptions, Misuses & Mistakes". This post summarizes the key statements of this presentation.

General Misconceptions

• C4 is new: Despite claims that it’s a recent innovation, the C4 model was created around 2007 and has remained largely unchanged since then.
• C4 replaces UML: C4 was never designed to replace UML but rather to offer a more structured approach to boxes-and-arrows diagrams. UML and C4 can complement each other.
• C4's blue and gray notation is mandatory: The model is notation independent, and users can employ any colors or styles they prefer.

Diagram Misunderstandings

• C4 forces too much text in boxes: Adding text improves clarity and reduces ambiguity. The trade-off is clutter, but this can be mitigated by creating simpler versions for specific use cases.
• Metadata in diagrams is unnecessary: Removing metadata (like whether something is a container or system) introduces ambiguity, making diagrams harder to interpret.
• C4 diagrams should show decisions: Architecture diagrams show the outcomes of decisions, not the decision-making process. Decisions should be documented separately using architecture decision records (ADRs).

Scope Misconceptions

• C4 omits the deployment story: While the core static structure diagrams don’t show deployment, deployment diagrams and runtime views can complement the model to capture deployment aspects.
• Microservices are better modeled without C4: C4 supports microservices but requires proper abstraction and alignment with ownership. For instance, microservices can be modeled as systems, containers, or groups of containers, depending on their context.

Misuse of Abstractions

• Container and component definitions are confusing: Containers are deployable units, while components are non-deployable elements inside a container. Mixing these abstractions leads to errors.
• Arbitrary levels of abstraction are better: Adding undefined levels of abstraction (e.g., "subcomponents") reintroduces the chaos C4 aims to avoid. Each level in C4 serves a distinct, defined purpose.
• Subsystems are necessary abstractions: Subsystems often create ambiguous or superficial diagrams that don’t convey meaningful information about the architecture.

Other Misconceptions

• C4 is incompatible with DDD or event modeling: These approaches are complementary, not conflicting. C4 shows static structures, while DDD and event modeling address other concerns.
• C4 is for monolithic systems only: C4 works equally well for monolithic and distributed systems but requires appropriate scaling practices, like creating individual diagrams for each microservice.
• C4 can’t scale: C4 supports large architectures by splitting diagrams per service or using interactive visualizations, reducing the complexity of any single diagram.

Specific Modeling Errors

• External containers should be detailed: Showing internal implementation details of external systems introduces coupling and volatility. Focus on boundaries and abstract interactions instead.
• Shared libraries as containers: Shared libraries are not deployable units (containers) but reusable code. Represent them within multiple diagrams as components or use visual cues to indicate shared elements.
• Message brokers as single containers: Model individual topics as containers rather than treating the broker as a single container. This approach highlights point-to-point and pub/sub relationships more effectively.

Takeaways

• C4’s essence: A set of hierarchical abstractions (systems, containers, components, and code) and diagrams (context, container, component, and code levels).
• Flexibility: It is notation independent (colors, shapes) and tooling independent (use any diagramming tools).
• Main value: Beyond diagrams, C4’s real strength is in fostering precise architectural discussions and clear identification of system building blocks.