[HN Gopher] Concrete Diagramming, a Lightweight Alternative to C4
       ___________________________________________________________________
        
       Concrete Diagramming, a Lightweight Alternative to C4
        
       Author : Veuxdo
       Score  : 72 points
       Date   : 2023-03-25 13:23 UTC (9 hours ago)
        
 (HTM) web link (www.ilograph.com)
 (TXT) w3m dump (www.ilograph.com)
        
       | aleken wrote:
       | This has nothing to do with explosives. In case you wondered.
        
         | hackeraccount wrote:
         | 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.
        
       | mechanical_bear wrote:
       | 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?
        
         | Veuxdo wrote:
         | Hi, author here. An API can be a concrete thing (created,
         | deleted, etc.) in cloud environments (e.g. AWS API Gateway
         | APIs).
        
       | midenginedcoupe wrote:
       | 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.
        
         | alixanderwang wrote:
         | 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).
        
           | Veuxdo wrote:
           | > 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
        
             | alixanderwang wrote:
             | 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.
        
       | baq wrote:
       | 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.
        
         | haolez wrote:
         | 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.
        
         | e12e wrote:
         | 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)
        
       | jasonpeacock wrote:
       | 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.
        
       | heisenbit wrote:
       | > 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.
        
         | Veuxdo wrote:
         | 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 :)
        
       | eurasiantiger wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2023-03-25 23:01 UTC)