Reference: Diagramming vs modelling on the c4model website.

The idea is to create a model of for a C1/C2 representation leveraging the power of cue to make reusable components.

ex:

package c1

//...
mySystem: c4.#System & {
         label: "my system"
         //...
}

package c2

mycontainer: c4.#Container & {
        //...
}

mySystem: c1.mySystem & {
        containers: [mycontainer]
}

My preference goes to a site generated with Hugo with the theme Docsy.

The goal of this issue is:

• to have the structure
• to have automation to continuously deploy the website
• to create a basic structure according to the divio documentation project.

This is about writing a first-step tutorial as explained in the divio documentation framework.

The goal is to have a simple system diagram with the live preview that you can tweak.

This high level architypes tool could also be used with actual golang code .

you could parse golang code and express it as Cue and render it into a structure .

by adding annotations to your golang you can then hint to the parser what it is .

Labels name examples such as service, data model, dto, etc etc

so then in a live web server you can see the logical component structure of a large golang project . As you add label annotations the diagram would update

You can take it further too and generate signalling code so that when the golang code is running you can see data flows in the diagram.

Even further can you can step throw via the web gui by sending stop events from the web gui down into the golang program.

https://github.com/RussellLuo/kun Uses annotations in the golang code to kick off code generation and so could be used to add the things I discuss above .

now just because you could does not mean you should .
but it makes golang code that teams work on more self describing and always produces component diagrams from the actual code .

Would love to here what you think …