this post was submitted on 21 Jun 2023
2 points (100.0% liked)

Experienced Devs

3950 readers
1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

founded 1 year ago
MODERATORS
 

We are considering using C4 for our architecture diagrams. Many diagramming tools (including Structurizr which was developed specifically for it) support C4. I wonder if there are others that use it and I would like to hear your experiences.

My initial assessment is as follows:

Pros

  • Diagram as code is a great way to keep things open to change.
  • It allows for better versioning
  • It enforces semantics into the diagrams. Instead of just thinking in terms of boxes and arrows, one need to dig deeper

Cons

  • It has a relative steep learning curve (one needs to study the DSL even though the end result is just boxes and arrows)
  • The tooling is not perfect. One needs to run a docker container to be able to navigate within the diagram (solution: there is also a SaaS offering)
  • Its view of architecture is somewhat limiting. It doesn't seem to be catered for augmenting the diagrams with other forms of diagrams (flowcharts, etc.) or text.
top 2 comments
sorted by: hot top controversial new old
[–] r0bbbo@programming.dev 1 points 1 year ago

I've used it with a lot of success at my current and previous companies. To address a few of your cons:

  • Engineers are quickly comfortable with the tooling and VS Code plugins give you quick feedback. You can also point the plug in at a hosted instance to avoid running a local instance in Docker

  • Separation of different types of diagram is often a bonus—too often have I seen architects try to cover too many concepts in a single diagram—instead a Context diagram should define your system and its neighbours, a Container diagram the major pieces of your system, a Component diagram verges on design and is a good place for engineers and architects to converse. If a container or component has a particularly complex workflow, then a supplementary flow diagram helps. If it uses an extraordinary pattern, then a class diagram might help, and so on.

[–] truthy@programming.dev 1 points 1 year ago

I've used C4 in different ways.

Using Structurizr Lite (docker): I do really like the "as code" aspect. The DSL is okay, the documentation of it not so much. But in the end, the tooling is too limited, and I've never come to terms with it. The diagrams becomes very locked in, and are cumbersome to export.

I'm not a fan of integrating SaaS solutions into the documentation workflow, but would really suggest that in favor of the Lite offering. Although I haven't used it.

Using C4 with ordinary tools: What I've come to use more, is using the conepts (and templates when available) with other, non-specialized tools. With Miro for example (there are templates). While not as cool as the "as code" way, it's an nice and accessible way of visualizing software systems.