C4 Model vs Nodinite Concept Mapping
C4 Diagrams is part of experimental builds. To access this capability, contact your sales representative.
This page provides a complete side-by-side mapping of the C4 model's terminology and the corresponding Nodinite Repository entities and properties used in C4 Diagrams. Use this reference when the documentation from c4model.com uses different language than what you see in the Nodinite UI.
Different Diagrams, Different Audiences
Terminology note: The C4 model also has a separate Software Architecture Diagramming Maturity Model with five organisational maturity levels (Level 1 Initial → Level 5 Optimising). That maturity model is about how an organisation practices diagramming — it is not the same as the four C4 diagram types described below.
The C4 model is named after four diagram types — Context, Containers, Components, and Code — that each zoom into a different level of detail. The official c4model.com site notes: "you don't need to use all 4 diagram types; only those that add value — the System Context and Container diagrams are sufficient for most software development teams."
Nodinite currently implements the System Context and Container diagram types:
| Diagram type | Shorthand | What it shows | Who typically benefits | Mapping on this page |
|---|---|---|---|---|
| System Context | L1 | Systems, people, and high-level relationships between them | Executives, product owners, architects | C4 Level 1 Mapping |
| Container | L2 | Applications, services, databases, and their interactions inside a boundary | Platform engineers, solution architects, dev teams | C4 Level 2 Mapping |
| Component | L3 | Internal modules or components inside a container | Developers, tech leads, code reviewers | C4 Level 3 Mapping |
| Code | L4 | Class diagrams and low-level implementation detail | Developers reviewing specific implementations | This is a feature outside the scope. You can get this layer from your tools hooked up with the Nodinite MCP endpoint. |
C4 Level 1 — Context Diagram Mapping
In a C4 Context diagram you describe who uses the system and what external systems it interacts with.
| C4 Model Term | C4 Notation | Nodinite Entity | Nodinite Property | Notes |
|---|---|---|---|---|
| Person | Person(alias, "Name", "Desc") |
System | C4Type = Person |
E.g., "Mobile User", "Finance Analyst" |
| Internal Software System | System(alias, "Name", "Desc") |
System | C4Type = InternalSystem |
Systems you own and operate |
| External Software System | System_Ext(alias, "Name", "Desc") |
System | C4Type = ExternalSystem |
Third-party, SaaS, or partner systems |
| Relationship / Interaction | Rel(from, to, "Label", "Tech") |
C4DiagramConnectors | Label + Protocol columns |
Arrow with label and technology shown |
| System Boundary | Implicit boundary around Internal Systems | Defined per-diagram by lane presence | — | Internal systems form the "box" |
C4Type Values at a Glance
C4Type |
Value | C4 Term | Mermaid emitted | |
|---|---|---|---|---|
InternalSystem |
1 | Software System (internal) | System(...) |
|
ExternalSystem |
2 | Software System (external) | System_Ext(...) |
|
Person |
3 | Person | Person(...) |
|
None |
0 | (not in C4 diagram) | (not emitted) | — |
C4 Level 2 — Container Diagram Mapping
In a C4 Container diagram you zoom into a system boundary and show its internal containers — the applications, services, databases, and message buses.
| C4 Model Term | C4 Notation | Nodinite Entity | Nodinite Property | Notes |
|---|---|---|---|---|
| Container | Container(alias, "Name", "Tech", "Desc") |
Service | C4ContainerType + C4Technology |
REST APIs, Databases, Message Buses, Web Apps, etc. |
| System Boundary / Layer | Boundary(alias, "Name") { } |
Domain | LaneOrder per diagram |
Domains become swimlane boundaries; ordering is per-diagram |
| Person | Person(...) |
System | C4Type = Person |
Same as L1 |
| External System | System_Ext(...) |
System | C4Type = ExternalSystem |
Same as L1 |
| Relationship | Rel(from, to, "Label", "Tech") |
C4DiagramConnectors | Label + Protocol |
Same as L1 |
| Person Role subtitle | Subtitle text under Person shape | System | C4PersonRole |
E.g., "Customer", "IT Administrator" |
| Technology label | Second parameter $techn in Container(...) |
Service | C4Technology |
E.g., "ASP.NET Core", "SQL Server" |
C4ContainerType Values at a Glance
C4ContainerType |
Value | C4 Container shape | Example Services | |
|---|---|---|---|---|
None |
0 | Generic container (unspecified) | Catch-all for other types | |
WebApp |
1 | Web application / SPA | Customer Portal, Admin UI | |
MobileApp |
2 | Mobile front-end | iOS App, Android App | |
API |
3 | Web API / REST / gRPC | Customer API, Order Service | |
Database |
4 | Database / datastore | Customer DB, Order DB | |
MessageBus |
5 | Message bus / queue / broker | Azure Service Bus, RabbitMQ | |
Microservice |
6 | Microservice | Shipping Service, Auth Service | |
Function |
7 | Serverless function | Nightly Sync, Azure Function | |
EventStream |
8 | Event stream | Kafka Topic, Event Hub | |
FileStore |
9 | File store / blob storage | Azure Blob, SFTP Folder |
C4 Level 3 — Component Diagram Mapping
In a C4 Component diagram you zoom into a single Container (Service) and show its internal components — the building blocks that together make up that service. This level is intended for developer audiences who need to understand how a specific service is structured.
| C4 Model Term | C4 Notation | Nodinite Entity | Nodinite Property | Notes |
|---|---|---|---|---|
| Component | Component(alias, "Name", "Tech", "Desc") |
[Integration][Integrations] | C4ComponentType |
The logical components inside a Service |
| Container Boundary | Boundary(alias, "Name") { } |
Service | Acts as the enclosing boundary | The parent Service forms the boundary |
| Relationship | Rel(from, to, "Label", "Tech") |
C4DiagramConnectors | Label + Protocol |
Same as L1 and L2 |
| Person | Person(...) |
System | C4Type = Person |
Same as L1 |
| External System | System_Ext(...) |
System | C4Type = ExternalSystem |
Same as L1 |
Domain Ordering — Per-Diagram, Not Global
A key difference between C4 model boundaries and Nodinite Domains:
| C4 Model | Nodinite Implementation | |
|---|---|---|
| Boundary definition | Defined per diagram with arbitrary text labels | Reuses existing Domains from the Repository — no new entities |
| Ordering | Defined by the order they appear in the diagram file | C4DiagramLanes.LaneOrder column — per-diagram, not a global Domain property |
| Reuse | A boundary label is just text; not reusable | A Domain can appear in multiple C4 diagrams with different lane orders |
This means: reordering Domains in one C4 diagram does NOT affect the Domain's position in the BPM designer or any other C4 diagram. The order is always scoped to a specific diagram.
Connector / Relationship Mapping
| C4 Model | Nodinite C4 Diagram | Notes |
|---|---|---|
Rel(from, to, "Label") |
C4DiagramConnectors.Label |
Directional arrow from source to target |
Rel(from, to, "Label", "Tech") |
Label + Protocol columns |
Protocol maps to C4 $techn |
Properties Added to Existing Entities
C4 Diagrams required adding a small set of new properties to existing Nodinite Repository entities. These are global properties — they are not per-diagram and will appear across the product wherever those entities are used.
New Properties on System
| Property | Type | Purpose | C4 concept |
|---|---|---|---|
C4Type |
Enum | Classifies the System's role in C4 diagrams | Person / InternalSystem / ExternalSystem |
C4PersonRole |
string | Subtitle shown under Person-type nodes | C4 Person description |
C4PositionHint |
Enum | Default placement hint (Top / Bottom) | Actor position relative to lane stack |
New Properties on Service
| Property | Type | Purpose | C4 concept |
|---|---|---|---|
C4ContainerType |
Enum | Classifies the Service as a C4 Container type | Container (API, Database, MessageBus, etc.) |
C4Technology |
string | Technology stack / platform label | C4 $techn parameter in Container(...) |
What Is NOT Changed
The following entities and tables are completely unchanged in the C4 Diagrams feature:
| Entity / Table | Why unchanged |
|---|---|
BPMs, BPMLanes, BPMPhases, BPMServices, BPMConnectors |
C4 Diagrams is entirely additive — BPM tables are not touched |
Domains global ordering |
Domain ordering is per-diagram via C4DiagramLanes.LaneOrder, not a Domain-level column |
TransportContracts, MessageTypes, Endpoints |
Contracts are scoped to Services and unchanged |
| Existing "Show in Mermaid" rendering on Integrations/Services | Continues to work as-is; C4 Diagram Mermaid View is a separate output |
Frequently Asked Questions
Why is the C4 "System" mapped to Nodinite "System" but the names look different?
In pure C4 model language, "System" means a top-level software system containing many containers. In Nodinite, the System entity represents any software product, organization, or platform — which maps naturally to C4's external actors (Person, ExternalSystem). The Service entity holds the detailed container-level information (what the system runs, how it communicates), which maps to C4 Container.
Can I use a Domain as a C4 "System Boundary" (the dotted box)?
Yes. In C4 Container diagrams, Domain swimlanes are rendered as Boundary(...) blocks in the Mermaid output. Each Domain lane becomes one boundary enclosure containing the Services placed in that lane.
What happens if a Service has no C4ContainerType set?
The Service will appear as a generic None container node in the diagram with no technology-specific icon. The diagram will still render. It is recommended to set C4ContainerType before including a Service in a C4 diagram for accurate notation.
Can I have the same Service appear under two different Domains in the same diagram?
Yes. This matches the existing many-to-many relationship between Services and Domains in the Repository (same model used by BPM). A non-blocking warning is shown when you drag a Service into a second lane in the same diagram, but the insert succeeds.