The C4 model for visualising software architecture (2017) • Hacker News Board

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

#31

Post by gonzo41 » Sun, Oct 22, 2023, 3:04 PM UTC

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.

You can't really make complexity go away. It just get's moved about. Auto creating diagrams will either mean specifying a new code artifact that will need to be kept up to date, and or create dependencies that will themselves fall out of sink with the code base. Or they'll be really simplistic and useless.

I think the best way to document a system is to write doco and just specifyc the intent of the system. What was this thing meant to do. That context is really useful for contrasting with the use of the system in a prod environment.

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

#32

Post by dexterbt1 » Sun, Oct 22, 2023, 3:14 PM UTC

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…

Interesting, as I kinda share also that there are lines to be drawn between software architecture, design and implementation (all three).

Much like in the real world building of real-estate for example, I see there are different roles between the architect vs the engineers vs. the foremen.

What do you draw the line? What concerns/areas are to be covered in each of these [arch vs design vs implem]?

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

#33

Post by maximinus_thrax » Sun, Oct 22, 2023, 3:15 PM UTC

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…

> I kind of subscribe to software architecture being like, a set of design decisions that guide the implementation

Do you mean software architecture is such as a set of design decisions? Or that software architecture is a set of design decisions?

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

#34

Post by IshKebab » Sun, Oct 22, 2023, 3:23 PM UTC

bdg wrote: post #16

IshKebab wrote: post #2

Interesting but I don't think this especially adds anything. The high level diagrams are great but then you can already make those without having to read any fancy visual model websites. The site even kind of admits this: > As an industry, we do have the Unified Modeling Language (UML), ArchiMate and SysML, but asking whether these provide an effective way to communicate software architecture is often irrelevant beca…

Having structured architecture conventions becomes more important when you have many architecture conversations across multiple people and would like to gain insights from the diagrams too.

But you don't need and official standard that everyone learns. Just use words. If your box is a class, write "class Foo". If your arrow means "contains 1 or more" just write that next to the arrow.

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

#35

Post by bdg » Sun, Oct 22, 2023, 3:28 PM UTC

simpaticoder wrote: post #15

layer8 wrote: post #7

Earlier 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…

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…

This requires a preset architecture standard that explains specifically what boxes and arrows are, and how boxes/arrows interact. Lots of software smears a logical box out over several folders in the code, sometimes even with entirely different names. I don't just mean people write non-cohesive code, I mean frameworks tend to prefer organisation by layer ("the views go in the view folder!") instead of organisation by module ("These things work and change together with a defined boundary").

You can have what you're asking for if you agree to a predefined architecture and everyone agrees to write code that way.

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

#36

Post by auggierose » Sun, Oct 22, 2023, 3:30 PM UTC

I watched the talk on the site, and I liked it. But I also immediately had the question: Where do my actual abstractions live? So, not the concrete instances of an abstraction that runs somewhere, maybe as a component, maybe as code, maybe even as a whole container; but the abstraction itself.

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

#37

Post by onetimeuse92304 » Sun, Oct 22, 2023, 3:39 PM UTC

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…

> I dunno, I kind of subscribe to software architecture being like, a set of design decisions that guide the implementation.

I think this is the one mandatory part of software architecture which is giving developers information to help them make their own design decisions without constantly deferring to the authority.

But the exact place where architecture ends and development starts varies a lot.

I like to think that architecture itself decides what is important from the architecture standpoint. If architecture decides a certain low level application detail is important, then it becomes an architecture detail.

In fact, in most organisation architecture controls at the very least some top level design like components, communication patterns, APIs and technology in use.

In some organisation architecture goes as far as individual classes. Not all classes, but maybe classes modelling the domain of the problem especially, if that model is used as a language for multiple project or even implemented as a shared artifact.

I think C4 is suitable for those organisations where architecture is concerned with more low level structure than just listing applications and their integration interfaces.

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

#38

Post by windlep » Sun, Oct 22, 2023, 3:45 PM UTC

simpaticoder wrote: post #15

layer8 wrote: post #7

Earlier 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…

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…

This is how I use the tool the author created, Structurizr. I auto-generate the initial diagrams, then manually fix it to make it more readable. We then check-in the JSON workspace export into our git repo. The first two levels of the C4 model don't change regularly, so this isn't a frequent process to repeat.

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

#39

Post by phlakaton » Sun, Oct 22, 2023, 3:59 PM UTC

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…

Mermaid's definitely not well-suited for the amount of text and text formatting that C4 requires. You can do it, but you will be jumping through hoops, and the autolayout breaks down pretty quickly when the arrows between boxes get chatty.

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

#40

Post by adrianN » Sun, Oct 22, 2023, 4:04 PM UTC

rewmie wrote: post #24

hobofan wrote: post #11

Earlier quoted context omitted.

So how would you expect to insight on whether the current code differs from the planned design documents? By always applying a lot of manual human labor?

> 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.