Most software architecture diagrams are a mess ... partly due to ad hoc notation, and partly because it's very unclear what the boxes represent. C4 resolves the latter problem by introducing a small number of predefined…
> Thank you, but by that argument, I could that for any diagramming / whiteboarding tool. In theory, sure, but the majority of diagramming/whiteboarding tools are not easily manipulated via code/an API. Structurizr is a…
Thank you! :-)
> Take Structurizr for example, it doesn't automatically create the diagrams for you The Structurizr DSL is designed for manual authoring (which is what most people tend to do), but there's nothing preventing you from…
I don't have the full context of what you're trying to model, but "two components deployed as one service" might be better represented as a container. If that's not the case, you can use the "group" concept to group…
> But C4 seems almost too lightweight to merit a name. Fun fact ... it actually didn't have a name for the first few years, and was just the approach I used and taught people on my software architecture workshops.
Many of the comments here seem to assume that "diagrams as code" == automatic layout. That doesn't need to be the case.
I know a number of organisations who have done/are doing this, and my key piece of advice is to look at modelling rather than diagramming. Note that I'm not necessarily suggesting a traditional UI-driven modelling tool…
C4 model creator here ... in a nutshell, the C4 model is: 1. a hierarchical set of abstractions to describe software systems, and 2. a hierarchical set of diagrams to visualise those abstractions. Benefits include it…
I created the C4 model (https://c4model.com) as a way to help teams agree upon a set of abstractions and diagram types to describe software architecture. That website also has a tooling section with some suggestions,…
> but there are existing solutions and frameworks out there, from the terrible (6 Sigma or EDS' BCL Framework) to the excellent (MSF 3, parts of the UML). That's a fair point, and I'm occasionally asked why I'm…
> any software architecture modeling model that relegates dynamic behavior to a 'supplementary' status is suboptimal Another explanation is that the static structure diagrams are what give the C4 model its name:…
> I didn't get the feeling that it has to be 4 diagrams and I pick and choose myself. Correct. I get the feeling that most teams using the C4 model tend to stick to the top two levels - System Context and Containers…
> But, no one part of code can document the whole _system_ to which it belongs, nor can e.g. Git commit logs (which I also highly value). For that, I absolutely need diagrams and technical writing. Yes, that's exactly…
I've seen a number of organisations where everybody has been given UML training, and mandated to use a specific UML tool. In reality though, everybody is just abusing UML class diagrams as a way to draw ad hoc "boxes…
+1 for DFDs ... UML was designed with OO programming languages in mind, and doesn't really fit well for diagramming functional languages (unless you start creating your own custom UML profile, which I don't see many…
With the C4 model, you typically treat your database schema as a "container", and save the deployment/infrastructure concerns (e.g. replication) for a separate deployment diagram.
As some background, the rationale behind creating the C4 model was to create software architecture diagrams that would be easy for anybody on the project team to understand. The example diagram you linked to is fairly…
Most software architecture diagrams are a mess ... partly due to ad hoc notation, and partly because it's very unclear what the boxes represent. C4 resolves the latter problem by introducing a small number of predefined…
> Thank you, but by that argument, I could that for any diagramming / whiteboarding tool. In theory, sure, but the majority of diagramming/whiteboarding tools are not easily manipulated via code/an API. Structurizr is a…
Thank you! :-)
> Take Structurizr for example, it doesn't automatically create the diagrams for you The Structurizr DSL is designed for manual authoring (which is what most people tend to do), but there's nothing preventing you from…
I don't have the full context of what you're trying to model, but "two components deployed as one service" might be better represented as a container. If that's not the case, you can use the "group" concept to group…
> But C4 seems almost too lightweight to merit a name. Fun fact ... it actually didn't have a name for the first few years, and was just the approach I used and taught people on my software architecture workshops.
Many of the comments here seem to assume that "diagrams as code" == automatic layout. That doesn't need to be the case.
I know a number of organisations who have done/are doing this, and my key piece of advice is to look at modelling rather than diagramming. Note that I'm not necessarily suggesting a traditional UI-driven modelling tool…
C4 model creator here ... in a nutshell, the C4 model is: 1. a hierarchical set of abstractions to describe software systems, and 2. a hierarchical set of diagrams to visualise those abstractions. Benefits include it…
I created the C4 model (https://c4model.com) as a way to help teams agree upon a set of abstractions and diagram types to describe software architecture. That website also has a tooling section with some suggestions,…
> but there are existing solutions and frameworks out there, from the terrible (6 Sigma or EDS' BCL Framework) to the excellent (MSF 3, parts of the UML). That's a fair point, and I'm occasionally asked why I'm…
> any software architecture modeling model that relegates dynamic behavior to a 'supplementary' status is suboptimal Another explanation is that the static structure diagrams are what give the C4 model its name:…
> I didn't get the feeling that it has to be 4 diagrams and I pick and choose myself. Correct. I get the feeling that most teams using the C4 model tend to stick to the top two levels - System Context and Containers…
> But, no one part of code can document the whole _system_ to which it belongs, nor can e.g. Git commit logs (which I also highly value). For that, I absolutely need diagrams and technical writing. Yes, that's exactly…
I've seen a number of organisations where everybody has been given UML training, and mandated to use a specific UML tool. In reality though, everybody is just abusing UML class diagrams as a way to draw ad hoc "boxes…
+1 for DFDs ... UML was designed with OO programming languages in mind, and doesn't really fit well for diagramming functional languages (unless you start creating your own custom UML profile, which I don't see many…
With the C4 model, you typically treat your database schema as a "container", and save the deployment/infrastructure concerns (e.g. replication) for a separate deployment diagram.
As some background, the rationale behind creating the C4 model was to create software architecture diagrams that would be easy for anybody on the project team to understand. The example diagram you linked to is fairly…