[NTARelix]

For the last few months my team and I have been working on standing up a system of libraries that other teams in our organization will use. From the beginning we decided that documentation was necessary from 2 perspectives:

1. Internal maintenance; to understand the system's depths and how it came to be in its current state

2. External consumption; to see the pieces of the system, how they work together, and how to use them

In my research I stumbled across several viable documentation techniques/patterns that seemed to help us reach our doc goals. We decided to combine 3 of those techniques:

1. C4 Model (https://c4model.com/)

2. Architectural Decision Records (https://adr.github.io/)

3. arc42 (https://arc42.org/)

The result feels like more documentation than anyone will ever read, but it has allowed us to create a complete self-service set of documents that should allow our library to be used broadly across the org without our team becoming something like a tool support team.

While demonstrating or describing our system to people across the org (not just devs) we found that pointing to the top 2 levels of our C4 diagrams has been incredibly useful at helping describe the system and the work we're doing in the system. We've also received fantastic positive feedback from our audience regarding the diagrams and their ability to help clarify the concepts being described.

We decided to embed our diagrams directly into our markdown docs. The raw markdown looks like this:

```

## How It Works

A person uses the app, the app is compiled from the code, the code is maintained by developers.

<!--

@startuml example-diagram

!include <C4/C4_Container>

Person(dev, "Developer", "A software developer")

Person(user, "User", "A person that uses the application")

System(app, "Application", "The application")

System(code, "Code", "Code repository")

Rel(dev, code, "Maintains", "Git")

Rel(code, app, "Produces", "Azure")

Rel(user, app, "Uses", "Web Browser")

@enduml

-->


```

This ends up being completely readable as a plain markdown file, but is enhanced by having a markdown preview tool like any of the major Git hosts (GitHub, ADO, etc.) because the PlantUML is hidden, but the diagram is presented graphically as a .png image. It also allows us to keep our documentation close to the code it represents, which has been a huge benefit in the organizing of documentation (vs adding another doc to the pile of outdated docs in our internal wiki).

[j1elo]

Wait, do you mean that if you write inline PlantUML source such as in your example, an "example-diagram.png" is generated from that code and loaded by the image tag?

That sounds too advanced although I could see an Sphinx doc plugin being able to do that, but not the more basic Markdown viewer in most hosts... so I'll guess that you meant to copy the embedded PlantUML lines to a temp file, and generate a .png, that gets stored together with the .md file.