Related:
The C4 model for visualising software architecture - https://news.ycombinator.com/item?id=21032805 - Sept 2019 (59 comments)
The C4 model for visualising software architecture (2017)
71–80 of 107 posts
Re: The C4 model for visualising software architecture (2017)
#72> 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.
Diagrams are similar to textual documentation: You generally can’t auto-generate useful ones from code, unless the code has extra markup that specifies what to generate. Diagrams often present a specific perspective that emphasizes certain features while omitting others. You might have several diagrams for the same entity, each illustrating a different aspect or scenario. The upshot is that diagrams have to be mainta…
I use diagrams for two distinct use cases :
- planning/outlining a solution
- documenting/insight into the system
I disagree that second can't be autogenerated - I've used class diagrams, database schema diagrams etc. to visualize projects, a lot of the time over the documentation - precisely because I can trust the generated diagrams to reflect current state.
Documentation is nice for context but I'd take good visualisation tools over most documentation I've seen on projects I've worked on.
Tooling to connect/validate documentation against code is non-existent, in my world at least. Maybe LLMs can change that down the line - have PR review against docs run as a part of CI/CD pipeline.
Re: The C4 model for visualising software architecture (2017)
#73Earlier 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…
I don’t think that’s the problem. There are so many different ways to look at a system. An architectural diagram shows you how components connect. A procedural diagram shows you what steps a program takes. An entity diagram shows you the major high level entities you’ve selected into your system. I just don’t see how a single language can express all the detail. Maybe a new one can be invented but I don’t see how S e…
> An architectural diagram shows you how components connect.
That's the one we're talking about here.
> A procedural diagram shows you what steps a program takes
Which is useful if the program is procedural.
> An entity diagram shows you the major high level entities you’ve selected into your system.
That's the top-level of your architectural diagram.
> I just don’t see how a single language can express all the detail.
When the program's architectural style is call/return, we can do this just fine. Using stepwise refinement we move up and down the abstraction ladder of our system and thus add/remove detail. No problem.
The problem is that most systems these days are not primarily call/return, but have to be programmed in call/return languages.
> I don’t see how S expressions solve this
I don't either, and have no idea what S expressions have to do with this.
> .... diagram generation is part of the language
It's not part of the language. But it's part of the frameworks, and when the abstractions of your language are architectural in nature, there is a very close correspondence between the code and the diagrams.
> ... discrepancies are a good teaching tool...
Yes, since the diagrams are generated, it's easy to keep older version around and generate new ones on-demand. Then you can check the differences visually, in code, or as the difference between code and diagram. Take your pick.
> Not until AI can actually start understanding sentiment from code.
Again, the point is that architecture is not actually "sentiment". It is structural. The fact that it looks like sentiment in practice is purely a side effect of our programming languages being incapable of encoding architecture in the general case.
Re: The C4 model for visualising software architecture (2017)
#74Earlier quoted context omitted.
Diagrams are similar to textual documentation: You generally can’t auto-generate useful ones from code, unless the code has extra markup that specifies what to generate. Diagrams often present a specific perspective that emphasizes certain features while omitting others. You might have several diagrams for the same entity, each illustrating a different aspect or scenario. The upshot is that diagrams have to be mainta…
> 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-one mapping between what bits of a software project are of critical importance to form mental models, and what bits are irrelevant.
> IMNSHO, the reason is that we don't have a way to express architecture in or as code.
Not true. We have more than plenty of ways to represent software architectures. That is trivial and a solved problem. So is mapping representations of software architectures to (some) source code, at least in the form of skeleton code. The problem lies in mapping software projects to a software architecture, even when the software project is clean and a textbook example of a very specific software architecture.
Re: The C4 model for visualising software architecture (2017)
#75The same article posted for the 14th time since 2017. https://news.ycombinator.com/from?site=c4model.com
Re: The C4 model for visualising software architecture (2017)
#76The same article posted for the 14th time since 2017. https://news.ycombinator.com/from?site=c4model.com
[deleted]
Re: The C4 model for visualising software architecture (2017)
#77The same article posted for the 14th time since 2017. https://news.ycombinator.com/from?site=c4model.com
Re: The C4 model for visualising software architecture (2017)
#78Even as a non civil engineer I can understand floor plans and alikes and find then immediately useful. Even as a professional SWE these example diagrams don't seem useful or informative enough to justify bothering with them. Code is too multidimensional to be approximated with 2d drawings. It just doesn't work. What could work are more conventional architectural code patterns. Things like structured concurrency, but…
Mostly because software architecture diagrams need a lot of context or have to be in specific context and quite tight scope.
Floor plan has really fixed context and very limited scope. Like I don't have to explain windows ... but in software most of the time you actually have to explain "window" because every "window" or element will be different, you cannot just say this is window and copy it 20x.
Re: The C4 model for visualising software architecture (2017)
#79Admittedly I'm a greybeard. Wrote my first app in 1984. Moved through the ranks, from support to dev roles, application architecture, enterprise architecture and finially process optimisation. And so wow, those diagrams in the links - how does one even manage all those boxes?!? Architecture is easier than coding, if you stay away from more/bigger/but_my_app_is_a_special_little_snowflake mantras. Consider the age-old,…
Nice, thanks.
Re: The C4 model for visualising software architecture (2017)
#80Earlier quoted context omitted.
> So how would you expect to insight on whether the current code differs from the planned design documents? Developers are expected to know what they are doing and how their software project is organized. > By always applying a lot of manual human labor? That "manual labor" has a name: software development. Software only changes if developers submit changes. Changes are reviewed as part of code reviews.
In all projects that I’ve worked on the code was much too complex for a single developer to have even a surface level understanding of all of it, yet one is regularly required to change unfamiliar pieces.
> In all projects that I’ve worked on the code was much too complex for a single developer to have even a surface level understanding of all of it, yet one is regularly required to change unfamiliar pieces.
That sounds like a self-inflicted problem, caused by a team failing to develop and maintain their system following basic software engineering principles. I'm not sure how diagrams are relevant.