c4 Model Forever Misconceptions Misuses Mistakes
c4 Model Forever Misconceptions Misuses Mistakes
Simon Brown
What is the C4 model?
#2 “Not everybody else on the team knows it.”
#3 “I’m the only person on the team who knows it.”
#36 “You’ll be seen as old.”
#37 “You’ll be seen as old-fashioned.”
#66 “The tooling sucks.”
#80 “It’s too detailed.”
#81 “It’s a very elaborate waste of time.”
#92 “It’s not expected in agile.”
#97 “The value is in the conversation.”
C4
c4model.com
A way to introduce some structure
to “boxes & lines” diagrams,
using a self-describing notation
Software System
Zoom in
Zoom in
Zoom in
http://thinkrelevance.com/blog/2011/11/15/documenting-
architecture-decisions (Michael Nygard)
fi
“ ”
C4 model omits the
deployment story
The C4 model was inspired by
UML and the 4+1 model
“ ”
We don't need C4 because
we do DDD instead
“ ”
I personally prefer Event Modeling
over C4. C4 has the major downside
that it does not re ect the concept of
time very well.
fl
Abstractions
and naming
“ ”
We renamed the abstractions to
software system, component,
sub-component, code
“ ”
We’ve adopted the Spotify model;
we use “software system”
to represent the capability
we (the squad) are building
“C4 is too limiting”
“ ”
A database is a database; debating
whether it is also a Container or a
Component just isn’t worthwhile.
“Concrete Diagramming Models, a Lightweight Alternative to C4“
www.ilograph.com/blog/posts/concrete-diagramming-models
“ ”
The problem is that systems today have many di erent kinds of
things. Servers, databases, virtualized containers, APIs,
pipelines, repositories, packages, libraries, and (many, many)
cloud resources are all real, concrete things that provide real
value. Forcing them into one of C4’s four levels of abstraction
doesn’t really accomplish much.
“Concrete Diagramming Models, a Lightweight Alternative to C4“
www.ilograph.com/blog/posts/concrete-diagramming-models
ff
What is a “database”?
“ ”
microservices shouldn’t
share a database
Be more precise with your
terminology … which is exactly what
the "system vs container vs
component" debate forces you to do
The power of the C4 model isn't the
diagrams, it's the small set of named
hierarchical abstractions that help
teams reason about their codebases
in a structured and more precise way
“ ”
Inspired by C4 Model and Structurizr DSL, but
with some exibility. You de ne your own
notation, custom element types and any
number of nested levels in the architecture
model. Perfectly tailored to your needs.
fl
fi
What is a
“component”?
“ ”
Component
a modular unit with well-de ned Interfaces
that is replaceable within its environment
https://www.omg.org/spec/UML/2.5.1/PDF
fi
Software System
Web
Application
Logging
Component
Relational
Database
Forcing them into one of C4’s four
levels of abstraction doesn’t really
accomplish much.
De ned abstractions
C4 model
fi
Abstraction
vs
organisation
“ ”
What are your thoughts on modelling
additional abstractions?
Subsystem
"part of a larger system"
Bounded context
Layers
Controller Layer
Service Layer
Repository Layer
Some of these concepts
might be better thought of as
organisational constructs
rather than abstractions
Message-driven
architectures
Service A Service C
Sends messages to Sends messages to
[Container] [Container]
Kafka
[Container]
Service B Service D
[Container] Sends messages to Sends messages to [Container]
Topic Y
Service B Service D
[Container: Kafka
[Container] Sends order creation messages to Sends order creation messages to [Container]
Topic]
Topic Y
Service B Service D
[Container: Kafka
[Container] Sends order creation messages to
Subscribes to order creation [Container]
Topic] messages from
Service B Service D
[Container] Sends order creation messages to [Container]
[via Kafka topic Y]
1. A software system
2. A container
3. A group of containers
What is a
“microservice”?
Stage 1: 💵
(monolithic architecture)
Stage 2: 💵 💵
(microservices)
software system
Stage 3: 💵 💵 💵
(Conway’s Law)
The C4 model at scale
In this example,
a microservice is
a combination of
an API and
a database schema
container softwareSystem {
include user
Include ->service1->
}
container softwareSystem {
include ->service2->
}
container softwareSystem {
include ->service3->
}
Dependencies to
“external” containers
My recommendation is that container
diagrams only show containers inside
the software system that is the scope
of the diagram
Container diagram for software system A
container a {
include *
}
Container diagram for software system B
container b {
include *
}
I don’t recommend showing
“external” containers
Container diagram for software systems A and B
container a {
include a.app b.api
}
Showing “external” containers implies
some understanding of
implementation details, which makes
the diagrams more volatile to change
This is a form of coupling
There may some useful exceptions
to this guidance…
Container diagram for software system A, showing a shared DB
container a {
include a.app c.db
}
Container diagram for software system B, showing a shared DB
container b {
include b.api c.db
}
The C4 model is…
https://leanpub.com/b/software-architecture
Simon Brown