3 ms·

I’m surprised no one has mentioned the C4 approach to diagramming yet, which is a prescriptive approach that helps to avoid most of these mistakes: https://c4mo

I’m surprised no one has mentioned the C4 approach to diagramming yet, which is a prescriptive approach that helps to avoid most of these mistakes: https://c4model.com/ https://c4model.com/

billyp-rva 2y ago
An important caveat is that C4 is narrowly tailored to monolithic software systems. When diagramming cloud or (micro-)service systems, its prescribed abstractions start to work against you. For example, there is no appropriate level for (e.g.) VPCs, virtualized containers, or abstract concepts like microservices. At that point, you’re left either abandoning C4 or debating with everyone about the exceptions you have to make to make it fit.
- tinix 2y ago
  c4 has a deployment extension, fyi. https://c4model.com/diagrams/deployment https://c4model.com/diagrams/deployment that being said I consider that an implementation detail.
photonthug 2y ago
> C4 approach to diagramming This highlights my only beef with TFA, since it seems to go against the advice to not mix abstraction levels. TFA is great advice for getting at least mediocre diagrams, informative and inoffensive. But the best diagrams are deliberately mixing levels to highlight stuff, because layer boundaries are usually where it gets tricky. Maybe none of this is relevant if you really want to split hairs about what architecture vs system vs component diagram “really” means, but I’m not aware of nonfuzzy definitions for that and most people seem to use the terms informally.
dadadad100 2y ago
There is some interesting new working the C4 space at https://likec4.dev/ https://likec4.dev/ This is a less prescriptive model than structurizr but keeps the goals of C4
- 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. This sounds limiting, but the power of C4 is that limited set of abstractions, and the conversations it forces architects/developers to have. The less prescriptive approach of LikeC4 sounds very appealing, because it provides a way to define your own abstractions. But I don't recommend this approach for most teams -> https://c4model.com/abstractions/faq#can-we-add-more-abstraction-levels https://c4model.com/abstractions/faq#can-we-add-more-abstrac...

I’m surprised no one has mentioned the C4 approach to diagramming yet, which is a prescriptive approach that helps to avoid most of these mistakes: https://c4model.com/ https://c4model.com/

billyp-rva 2y ago

An important caveat is that C4 is narrowly tailored to monolithic software systems. When diagramming cloud or (micro-)service systems, its prescribed abstractions start to work against you. For example, there is no appropriate level for (e.g.) VPCs, virtualized containers, or abstract concepts like microservices. At that point, you’re left either abandoning C4 or debating with everyone about the exceptions you have to make to make it fit.

tinix 2y ago
c4 has a deployment extension, fyi. https://c4model.com/diagrams/deployment https://c4model.com/diagrams/deployment that being said I consider that an implementation detail.

photonthug 2y ago

> C4 approach to diagramming This highlights my only beef with TFA, since it seems to go against the advice to not mix abstraction levels. TFA is great advice for getting at least mediocre diagrams, informative and inoffensive. But the best diagrams are deliberately mixing levels to highlight stuff, because layer boundaries are usually where it gets tricky. Maybe none of this is relevant if you really want to split hairs about what architecture vs system vs component diagram “really” means, but I’m not aware of nonfuzzy definitions for that and most people seem to use the terms informally.

dadadad100 2y ago

There is some interesting new working the C4 space at https://likec4.dev/ https://likec4.dev/ This is a less prescriptive model than structurizr but keeps the goals of C4

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. This sounds limiting, but the power of C4 is that limited set of abstractions, and the conversations it forces architects/developers to have. The less prescriptive approach of LikeC4 sounds very appealing, because it provides a way to define your own abstractions. But I don't recommend this approach for most teams -> https://c4model.com/abstractions/faq#can-we-add-more-abstraction-levels https://c4model.com/abstractions/faq#can-we-add-more-abstrac...