HackerTube

Visualising software architecture with the C4 model - Simon Brown, Agile on the Beach 2019

Agile on the Beach3 HN recommenders · 2021–2023
553K views · talk · evergreen · Uploaded 2019-08-16

Simon Brown's Agile on the Beach 2019 talk presents the C4 model, a lightweight approach to diagramming software architecture with a shared vocabulary and simple notation.

Recommended as the introduction to C4 when people ask how to visualize and communicate software architecture.

Software architecture & design

Watch on YouTube

4 comments from Hacker News

@tmountain2021 · in “Beyond Whiteboarding: Creating Expert System Architecture Diagrams”

These fail my litmus test, which is, "can a third-party look at the diagram and make sense of it without verbal explanation?" For a more formal approach to coherent diagrams and white boarding, I recommend the C4 model. It's conceptually simple and results in better system documentation than the free form method that's commonly used. [VIDEO]

RecommendsView on HN
@qrian2022 · in “Ask HN: Visualizing software designs, especially of large systems (if at all)?”

Recently stumbled upon [C4 Model]( [VIDEO] ), which seemed very promising. It builds on the failure of adopton of UMLs, and aim to be practical and communicative.

RecommendsView on HN
@chrsig2023 · in “Architecture diagrams should be code”

I've looked at mermaid & planetuml before. structurizr is new to me and looks interesting. PlanetUML has the advantage of gitlab support, iirc -- allowing rendering of diagrams in README files. I'd like to see more options for that. edit: interestingly, the author of structurizr (Simon Brown) was recently linked in another HN thread. HN thread - [LINK] YT link - [VIDEO]

CitesView on HN
@SnowProblem2023 · in “Architecture diagrams enable better conversations”

If C4 is new to you too, I recommend their intro video: [VIDEO] . It feels like a very light ruleset over what we would do naturally when explaining a system to another engineer. That's great. Some of the ideas that stood out were: 1. Allow flexibility in the notation (shapes and color) as long as the abstractions are good. 2. When drawing arrows, make them unidirectional to show the main intent. 3. Hide details to express the main story (@ 27min in the video) 4. Don't just give names to components. Give short descriptions too. 5. Don't document the lowest levels. Code is better here.

RecommendsView on HN