Architecture, distribution and integration
Component responsibility map — C4-style
Inside one container: its components and how they collaborate.
c4.component@1New DDN source
Why use it?
This is where most day-to-day design discussion actually happens.
When it helps
Designing or reviewing the inside of a service or application.
How to read it
- Components are code-level units with names you can find in the repo.
- Collaborations read as "calls for purpose", not "uses".
What you need
- The component list
- Responsibilities per component
- The collaboration paths
Things to check
- Do not invent components that have no code counterpart.
- Do not let every component talk to every other — that is a missing component.
Scope of this diagram
C4-style equivalent; not a code-structure certification.
Work with the converted example
- Open the viewer and select
component. Inspect the rendered view and its source. - Open the designer. Keep the selected profile and inspect its legal palette and property controls.
- Change one displayed title or an appropriate data value. Apply the edit and check the resulting diagram.
- Run the verifier and review its diagnostics before moving complete content into review.
- Download your edited DDN source to retain the change.
The example uses the indentation-based ddn-next-1 dialect. The language guide explains reusable definitions, dotted data rows and explicit property blocks.