C4 Model

Solutions

Structurizr
C4-PlantUML
IcePanel
Carbide
hasHighlight
- To document a library, framework or SDK, you might be better off using something like UML
- Sometimes diagrams work better showing dependency relationships (e.g. uses, reads from, etc), and sometimes data flow (e.g. customer update events) works better.
  - most relationships can be expressed either way, and the more explicit you can be, the better. For example, describing a relationship as "sends customer update events to" can be more descriptive than simply "customer update events".

From Ilograph

Concrete diagramming models are bottom-up, fact-based models that prioritize hard information over generalizations.
Abstract resources are intangible and purely conceptual. Their very existence has an eye-of-the-beholder quality to it. From computing, abstract resources include things like services and domains.
- e.g. Order Service and User Service (rendered in green) are the abstract resources. These services exist only conceptually; they are nothing more than a convenient way of grouping APIs, Lambdas and database tables. Like concrete resources in the previous section, they can be used to demonstrate higher-level relations and interactions

using domain-specific abstractions makes more sense than using arbitrary ones. Diagram authors benefit from thinking about each system on its own terms (and in its own terms). Diagram viewers do, too.
The top-down, abstraction-first approach of C4 risks focusing too much on a system’s abstractions at the expense of its concrete resources.

Backlinks

Solutions