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

21–30 of 107 posts

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

#21

Post by growse »

hobofan wrote: post #11
rewmie wrote: post #9

Earlier quoted context omitted.

> 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. Architecture diagrams document how the software is expected to be organized. They represent the goal, not the current state. The code needs to comply with the diagram, and not the other way around. The only scenario where it makes sense to generate…

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?

This is not a trivial problem to solve. Some would say that one of the entire points of software engineering is to assure that the code meets the design spec. A more rigorous approach would be to encode your design as a bunch of linting rules that you could run against your codebase (IaC and all).

I'm pretty sure that auto generating a diagram from some code and then trying to work out if it's semantically equivalent to something that was hand drawn is not the answer though. For one thing, the code doesn't contain or implement every single important aspect of the design.

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

#22

Post by motohagiography »

I like the model, and have had to use UML in security architecture where the whole thing hinges on consistency from the top level context to the code. The simplicty of this C4 model is a forcing function, where if there is hidden context or components, they have to shake out in the model. I'd suggest resistance to something this simple chould indicate there may be hidden elements (which there are more often than not on large projects). Forcing people to clarify their thinking into something like this decentralizes them by having them commit to statements and ideas instead of just reserving a right to suggest and criticize, and you can get a lot of resistance to that as well. These aren't model problems though, but they're what happens when models meet people.

I'll use something like this as a reference for security design as I really like its consistency.

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

#23

Post by bdg »

nickdothutton wrote: post #19

This is how you know software engineering is still an immature discipline. It’s 25+ years (in my case) as still we are having largely the same discussions about “basic” things. I’m not saying this is bad, but progress is slow, and we can’t blame any particular company or consortia or commercial interest here.

Honestly we have the same problem outside of engineering. C4 is really just a way to focus conversations along one level of abstraction.

How many times have you talked to someone who bounces up and down from high detail high complexity to zoomed-out simplicity in the same thought, and not understood what they wanted to tell you? We have the same issue when devs think "I will just yolo some boxes and arrows on this board, it makes sense in my head so it is a good diagram!"

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

#24

Post by rewmie »

hobofan wrote: post #11
rewmie wrote: post #9

Earlier quoted context omitted.

> 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. Architecture diagrams document how the software is expected to be organized. They represent the goal, not the current state. The code needs to comply with the diagram, and not the other way around. The only scenario where it makes sense to generate…

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.

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

#26

Post by mikehollinger »

I like C4. I'd previously discounted the "context" diagrams that inevitably show "User -{do their job}-> System-of-Record" as useless. Now I see the point.

I'm working through a new piece of system design for a complex system using C4 with our extended teams.

In drawing the top level this time around though I realized that b/c we have a semi-disconnected mobile app (aside from a web UI) we need to degrade certain behaviors gracefully if we don't have certain results yet, either b/c we're offline, or the backend is just slow for some reason.

That rippled down into the next layer of the system as a job queue, which then rippled into the UX, because we can now say definitively which parts of the system may take an unbounded amount of time to complete a request.

I'm sure we'd have gotten to this conclusion eventually but the analysis put the issue front and center.

All because I had to draw a picture with "Remote-User --{Mobile Stuff}--> Backend."

Also whichever tool you use is up to you. I just use draw.io for example with different tabs for each layer. As we elaborate on this at some point we'll break the lower layers out to their own files.

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

#27

Post by jhund »

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…

Plus one for structurizr. Its model driven approach makes it a lot easier to keep the diagrams consistent with the code: You describe the architecture, and structurizr renders the diagrams.

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

#28

Post by mumblemumble »

layer8 wrote: post #7
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.

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…

Agreed. I experimented with autogenerating C4 diagrams from source a while back, but quickly abandoned the project when I realized that the output was inevitably the flowchart equivalent of

  bool mystery_func(int i) { // define a new function
    int x = (int)(i / 2);    // x is i divided by 2 and truncated
    int y = x * 2;           // y is twice x
    return y == i;           // return true if y == i
  }                          // end of function

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

#29

Post by wokwokwok »

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 retrospectively documenting an existing codebase.

> It's a way to create maps of your code, at various levels of detail, in the same way you would use something like Google Maps to zoom in and out of an area you are interested in.

This seems different.

I have no idea why you would refer to the a code diagram as your software architecture. That's literally the code level. How is that architectural?

It's like saying the circuit diagram in the plug should go on the house blueprint. "You should use automated tools for this" ... so, it's for documenting existing code bases at the per-function level?

How is that useful for architecting / designing / planning software?

That sounds like software structure to me, not software architecture.

Sure, a map of existing software that explains how it's structured sounds cool... but I dunno. Like, if you're talking about design patterns, you're not gonna give someone a function-by-function map of how to implement a singleton. They're not stupid. You'd tell them you think it should have a singleton (or repository, or whatever).

Software design is totally a thing, and this seems entirely reasonable for designing software.

...but software design and implementation and software architecture are not the same thing and they're not done by the same people, in my experience.

This feels more like... systems design, which a software architect would contribute advice to in the way that the systems were designed so they aligned with good software architecture principals.

Maybe I'm just being pedantic. /shrug

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

#30

Post by chrisweekly »

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…

Excellent points.

(also, not too pedantic)

(also, principals -> principles)

Post reply on HN