The C4 Model – Misconceptions, Misuses & Mistakes • Simon Brown • GOTO 2024

The C4 model consists of four levels of abstraction: Context, Containers, Components, and Code, designed to show different views of software architecture to different audiences

C4 is notation-independent and tooling-independent - the core value is in the abstractions and model, not specific diagram styles or tools

The top two levels (Context and Container diagrams) are the most important and recommended starting point - additional levels can add unnecessary complexity

Microservices can be modeled in C4 as containers with APIs and database schemas, with clear system boundaries reflecting team ownership

C4 works well for both monolithic and distributed architectures - it’s about reflecting reality and reducing the model-code gap

Shared components and libraries should be modeled based on deployment boundaries - if separately deployable, model as containers; if not, as components

Adding metadata and clear naming to diagrams is crucial for removing ambiguity - notation should be self-describing

C4 complements rather than replaces other approaches like DDD or event modeling - they can be used together effectively

The model supports documentation through different views (static structure, deployment, dynamic) while keeping consistent abstractions

Common misconceptions include C4 being too limiting or unsuited for modern architectures - in reality it’s flexible and can adapt to different needs while maintaining clear structure