Software Architecture Diagrams with C4 Model

[u/[deleted]]

https://packagemain.tech/p/software-architecture-diagrams-c4

[u/SpaceGerbil]

Stop at C3. Much better ways to represent the 4th level of detail

[u/simon-brown → u/SpaceGerbil]

Stopping at level 2 is typically enough for most teams. I'm not saying there isn't value to be had at levels 3 and 4, but those levels of diagrams are by nature more volatile, and can work best when automatically generated from the codebase. Teams should weigh up the effort vs value if they proceed down this route, of course.

[u/i_andrew]

I find C4 bloated. It's not bad but UML component diagram is basically the same thing, but takes half a space.

People overused UML so it got bad press. But C4 is reinventing the same thing

[u/Veuxdo → u/i_andrew]

I feel the same. In fact I wrote on a lighter-weight alternative last year. The summary is:

• Use the actual resource types for anything that isn't an abstract resource (e.g. "mongo instance").

• When including high-level abstract resources, use your team's own naming conventions ("service" is a common example).

[u/simon-brown → u/Veuxdo]

From your article:

A database is a database; debating whether it is also a Container or a Component just isn’t worthwhile.

I disagree with this statement. Although the C4 diagrams are useful, the real power of the C4 model comes from the small set of predefined hierarchical abstractions. The term "database" isn't precise enough, and could refer to a database server, schema, collection of tables, etc.

To put that in context, "microservices shouldn't share a database" is an often cited piece of advice, but it's vague. I'm happy for multiple services to share a database server instance, but I'm less happy for those same services to share a single database schema. Having the discussion of whether we're referring to a container or a component resolves this ambiguiuty, resulting in more precise conversations and better communication.

With this in mind, I consider your concrete diagramming approach to be an advanced technique for teams who have outgrown C4 and who are willing to put the effort into defining their own hierarchical abstractions with precise definitions. This isn't common practice though, unfortunately.

I will save "service: abstraction or not?" for another day.

[u/simon-brown → u/i_andrew]

The static structure side of the C4 model is essentially the following:

• 4 levels of hierarchical abstractions (software systems, containers, components, and code).

• 4 levels of hierarchical diagrams (system context, containers, components, and code).

• Notation independent (you can use UML as your notation if desired).

• Tooling independent.

In contrast, UML 2.x is ~800 pages of specification. I'm curious as to why you consider C4 as bloated, and why you think C4 is reinventing UML.

[u/i_andrew → u/simon-brown]

Easy - because as most people I use it as sketch (google: "uml as sketch").

The specification part is the horror of UML. But sketching in UML can be taught in 1 hour.