simon_brown

6 ms·

1.
by simon_brown 2y ago
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 abstractions. T
2.
by simon_brown 2y ago
> 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 mo
3.
by simon_brown 2y ago
Thank you! :-)
4.
by simon_brown 2y ago
> 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 writing s
5.
by simon_brown 3y ago
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" concep
6.
by simon_brown 3y ago
> 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.
7.
by simon_brown 4y ago
Many of the comments here seem to assume that "diagrams as code" == automatic layout. That doesn't need to be the case.
8.
by simon_brown 4y ago
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 here. My op
9.
by simon_brown 5y ago
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 providing teams with a
10.
by simon_brown 5y ago
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 you mig
11.
by simon_brown 7y ago
> 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 "
12.
by simon_brown 7y ago
> 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: Context, Contai
13.
by simon_brown 7y ago
> 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 (these levels al
14.
by simon_brown 7y ago
> 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 why I use the
15.
by simon_brown 7y ago
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 and lines&quo
16.
by simon_brown 7y ago
+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 people doing).
17.
by simon_brown 7y ago
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.
18.
by simon_brown 7y ago
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 typical of what most t