Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C4 model for visualising software architecture (2017)

c4model.com

Post reply on HN
Print view View original

91–100 of 107 posts

Re: The C4 model for visualising software architecture (2017)

#91

Post by zoom6628 »

In the 80s I learnt SSADM and it was great for making sure business logic and architecture were understood and viable before a line of code was run. Which was very important on old mainframes with several hour turnarounds on compiles.

For last few decades I have only used diagrams to design and to explain. Have found too hard to keep diagrams up to date when iterating on compiles multiple times per hour.

What I feel is needed is ways to keep code, infra and spec in sync throughout the lifecycle.

Re: The C4 model for visualising software architecture (2017)

#92

Post by mpweiher »

rewmie wrote: post #74
mpweiher wrote: post #64

Earlier quoted context omitted.

> You generally can’t auto-generate useful [architecture diagrams] from code, The question is: why is this the case? IMNSHO, the reason is that we don't have a way to express architecture in or as code. Instead, we have to compile the actual architecture of the system into one that is expressible using the call/return architectural style that our programming languages support. That's a lossy process. When we can prog…

> The question is: why is this the case? Diagrams capture and represent abstract and/or high level concepts. Their goal is to provide a kind of mental map of how specific aspects of a project are organized in order to help developers form their mental models. This means placing the focus on key constructs and downplaying the importance or relevance of other components. There isn't an objective way to provide a one-to…

You are confusing “implement” and “express”

If the architecture were directly expressed in the code, mapping back would be trivial. It is not because we effectively compile the actual architecture in order to express it in code. Mapping back then becomes decompiling, with the added complications of architectural mismatch and manual compilation.

Re: The C4 model for visualising software architecture (2017)

#93

Post by capn_duck »

I've always been unsure where this stuff fits in. Do you make it before your system is built, when its unclear how where all the cards will fall? Or after your system is made and in production and all the warts of reality are present and your graph is not so nice and neat anymore. This seems like an architects picture of things. Close enough to give people the false confidence to think they understand things, but not close enough to be of use to anyone actually working in the salt mines.

Re: The C4 model for visualising software architecture (2017)

#94

Post by jakewins »

falcor84 wrote: post #20
simpaticoder wrote: post #15

Earlier quoted context omitted.

The correct solution is a synthesis: generate the boxes and arrows from code. Then let a human hide, move, and style those objects. When the code changes, the boxes and arrows will change, and perhaps the style will want to change, but at least the diagram will remain correct. This is precisely the distinction between semantic markup and css, btw. Implying that the html would be auto generated, the css would be hand…

I would actually be really interested in a bi-directional workflow, such that I would also be able to perform system redesign by changing the diagram's connections - the tooling will then automatically update the interface and the tests such that I wouldn't be able to commit my changes until the implementation matches the diagram.

I realize this isn’t what you’re arguing for, but as a cautionary anecdote on this topic:

Paul alludes to it in his post about Healthcare.gov from the other day, but this was apparently one of the major parts of the failure there - endless lines of code generated from UML diagrams, making reading the code hard and things like “can we add a trace statement here” difficult.

Optimising for diagrams-as-source-of-truth has drawbacks for debugging and maintainability of the running code

https://www.pauladamsmith.com/blog/2023/10/the-10-year-anniv...

Re: The C4 model for visualising software architecture (2017)

#96

Post by BerislavLopac »

ryan-duve wrote: post #3

> Ideally this diagram would be automatically generated using tooling... The biggest problem I've seen with architecture diagrams is they fall out of sync with the code base. In my opinion, automatic generation of these diagrams is necessary. Otherwise, teams have no way to know whether the picture in front of them accurately represents the latest state of the system.

The idea of C4 is to document the higher-level elements of the system - applications, components and the like. The first three Cs stand for "context", "container" and "component", while the fourth level, "code" is deemed optional.

IcePanel [0], a great tool for building C4 documentation, renames "containers" to "applications" for clarity, and instead of code diagrams simply links to the corresponding repos.

[0] https://icepanel.io/

Re: The C4 model for visualising software architecture (2017)

#97

Post by simon_brown »

williamdclt wrote: post #46
discodachshund wrote: post #8

I get the points about not needing a formalised system for diagrams, even if C4 is quite light touch in my opinion (I never go down to the code level). However, I do have to credit structurizr, which outputs C4 diagrams, as a great productivity boost. One model producing multiple views at all specificities is fantastic compared to mermaid, plantuml, etc, where every diagram needs to be self contained and define and r…

I’ve only tried structirizr briefly, but I found it too inflexible. No way to draw concepts that aren’t strictly part of C4. For example I wanted to encapsulate 2 components in a box to represent that they’re currently deployed as one service (not necessarily a good thing to do in absolute but would have helped my team to grok it better): impossible. I do like the idea of describing architecture formally, but the lac…

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" concept to group components together -> https://docs.structurizr.com/dsl/cookbook/groups/

Alternatively, https://likec4.dev provides a way to create an arbitrary number of abstraction levels (although I wouldn't recommend such an approach).

Re: The C4 model for visualising software architecture (2017)

#98

Post by eitland »

manicennui wrote: post #60
jackblemming wrote: post #49

You can see a crappy house that’s falling apart pretty easily. Conversely management cannot see a crappy codebase that’s rife with technical debt. Maybe they would make more intelligent decisions if they could visualize the problem.

Code quality does not seem to have any correlation with business success. Why should business care?

If you think about code quality in terms like line length, spelling errors, etc it might not matter.

If you think of it in terms of:

- how long does it take to get at new developer up to speed? (everything from readability to build systems)

- can this be hacked any day of the week if someone puts their mind to it? (both own code and libraries)

- can we be resonably sure that new changes don't introduce (large) defects? (testing, modularization)

it becomes impossible to argue that it cannot affect business success.

Yes:

- it might work as long as the old dev is happy and alive, but break down when he isn't available anymore

- it might work as long as nobody targets this business specifically

- it might work as it exist now but at some point be impossible to update anymore and the day new tax rules or whatever are introduced, it breaks

Re: The C4 model for visualising software architecture (2017)

#99

Post by datadrivenangel »

wokwokwok wrote: post #29

I dunno, I kind of subscribe to software architecture being like, a set of design decisions that guide the implementation. That's what (in my experience) most software architects do; lay down guidance and structure for the software engineers. > The C4 model was created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectiv…

C4 for housing would be:

* Have a high level blueprint of the house for typical humans.

* Have a detailed blueprint of the house for contractors.

* Have a circuit diagram for the utility systems like electricity

* (Optional) Have a detailed specification for every plug and fixture etc.

Basically, have a diagram for every level that will be notably unique or useful to have for the system. If you need a code level diagram, either you're doing some complicated custom work or most likely over specifying the design that can be left as an implementation detail.

Post reply on HN