Concrete Diagramming, a Lightweight Alternative to C4 | Hacker News Reader

Concrete Diagramming, a Lightweight Alternative to C4

ilograph.com

85 pointsVeuxdo16 comments

Those are sequence diagrams, which are not part of C4.

And honestly, they are not great sequence diagrams - too much emphasis on the things makes it hard to see the relationships/steps between things.

The dynamic shifting between different layouts is cool, but that's a tool feature - not a model feature.

> Concrete diagramming models are domain-agnostic; they are used to diagram any type of system. They can be used with any diagramming tool; however, for best results, model-based diagramming tools are recommended over generic drag-and-drop tools.

Making a statement on the superiority of model based diagrams vs. ad-hoc diagrams without any backing rationale? Adoption of such tools over the past decades outside of niches tell a different story.

Hi, author here. The article isn't about model-based vs. ad-hoc (at least, that wasn't my intent). Ad-hoc diagramming obviously has its (rightful) place. Whiteboards wouldn't be ubiquitous in offices otherwise :)

I’m using C4 whenever I need to design something which at least partially doesn’t exist yet. At this stage I’ve no idea which resources will be concrete or even if the abstraction won’t implode due to an unforeseen issue with implementing it.

So yeah concrete components are more important, but abstractions help you identify where concretization should be happening.

From tfa:

> Concrete diagramming models are bottom-up, fact-based models that prioritize hard information over generalizations. They are ideal for creating diagrams with lots of detail, such as when diagramming existing systems.

(My emphasis)

I've been using C4 as well and it's been working just fine. Sometimes I get confused about what should be a container and what should be a component (on large systems), but that's about it.

That looks nice.

The one thing I don't get though is who leaves their documentation artifacts to a SaaS? You're a pricing change / company collapse / systems outage / unacceptable ts&cs change away from losing your docs.

Right. It's okay to leave written documentation on SaaS (e.g. Notion), because the text is the artifact. If they're shutting down, or I don't like them anymore, I just move the text. But if Ilograph goes down, all I have is useless YAML.

Our team went through this thought process when we decided to open source our text-to-diagram language, users need to be able to reproduce their docs even if we shut down (https://github.com/terrastruct/d2).

> But if Ilograph goes down, all I have is useless YAML.

Depends. If you're using Ilograph Desktop [0], an outage won't affect you. And both with Ilograph Desktop and paid versions of the web app, you can export your diagrams to standalone HTML files. These artifacts will live forever.

[0] https://www.ilograph.com/desktop/index.html

I moved from Notion because of too many bugs, outage is just one of many scenarios where you'd want to bail, and not a primary one because it's not like a diagram service is in the customer path.

The HTML files are also not enough for me. It's like a bricked artifact. I can't modify my diagrams anymore. Like if I adopted a company's programming language and they assured me my assembly code artifacts will live forever.

This has nothing to do with explosives. In case you wondered.

My favorite version of this was a single panel cartoon in the college newspaper. It's a guy in the classic railroad worker outfit - peeked cap and striped bib overalls - sitting at desk thinking "Man, I need to read the course descriptions more carefully." The blackboard has Engineering 101 written on it.

From the get-go this seems much less abstract than C4 and that is not a good thing, since it makes diagrams less useful, much less readable and ultimately creates maintenance work.

How is it that a domain is an abstract entity, when something like an API is concrete? They are both something that is interacted with in the system? Or is it purely contextual based on the perspective of the person/team preparing the diagram?

Hi, author here. An API can be a concrete thing (created, deleted, etc.) in cloud environments (e.g. AWS API Gateway APIs).

I don’t see the value in this niche. Either I want to model something more abstractly, or I want to be more concrete and model precise data flows (defining programming as input data + transformation -> output data).

The article mentions “long-term”, but I certainly don’t want to maintain diagrams parallel to code. The reason it talks about modeling existing systems is that nobody did it in the first place, because it goes out of sync. Schemas are usually used to generate code or generated from code.

The criticism of C4 is also ironic. The same OOP/UML worries of what to name something or categorize it as apply.

Reply on news.ycombinator.com