Structurizr alternative: keeping the model true without typing it twice

Before Structurizr, C4 diagrams were four unrelated drawings that disagreed with each other. Structurizr replaced them with a single model: define the people, software systems, containers, and components once, then declare views onto that model. Rename a container and every view that shows it follows, which is the property no drawing tool can give you.

The DSL defines nine view types: systemLandscape, systemContext, container, component, dynamic, deployment, filtered, image, and custom. It is plain text under version control, so architecture changes arrive as pull requests and get reviewed like code. Diagrams are interactive and embeddable, keys are generated rather than drawn by hand, and the tooling ships in several shapes: a hosted service, an on-premises install, and Structurizr Lite for running a single workspace locally.

For a team that wants strict C4 conformance and a model under review, that combination is still the reference implementation. An alternative page that pretends otherwise is not worth reading.

The model is authored by a person, with one exception worth naming precisely. The structurizr-component library discovers components in a Java codebase through Apache Commons BCEL and JavaParser with pluggable type matchers, and the DSL exposes it as the !components keyword. It reads Java types. It does not read the Terraform that declares the managed database, the Helm chart that added a sidecar, or the CI workflow that says where a container ships, so the containers, the datastores, the queues, the boundaries, and the relationships between them are still typed in by whoever maintains the workspace.

That means the model has no feedback loop. When a service is deleted, when a queue is replaced by a topic, when a new database appears in a Helm chart, nothing in Structurizr notices. The workspace stays exactly as true as the last time someone with the context sat down with it, and the interval between those sittings grows with every sprint.

The failure is quiet, which is what makes it expensive. A diagram that is obviously broken gets fixed. A diagram that is mostly right gets trusted during an incident, and the part that is no longer true is where the outage is.

Datadef takes the other side of that trade. Connect the repository read-only, pick a branch or tag, and it reads a bounded set of the most architecture-dense files: infrastructure as code, containers and orchestration, database schemas and dbt models, API specs, CI pipelines, and manifests, plus a compact summary of the directory tree. It reads the repo first, then asks what you want drawn, so the altitude of the diagram is a decision you make once rather than a DSL you maintain forever.

Bounded is a number rather than a posture. Selection stops at 40 files or 250KB, whichever comes first, and truncates any single file past 30KB with a visible marker. Files are taken in priority order, infrastructure as code first and prose last, under per-class ceilings so one loud class cannot take the whole budget: on the architecture focus that is 16 infrastructure files, 14 Kubernetes manifests, 10 CI workflows, and 3 dbt models. Lockfiles, binaries, and directories like node_modules and .terraform are never candidates at all.

The output is grounded in those files. Architecture that appears nowhere in them will not be drawn, which is a real constraint and a deliberate one: it is the reason the diagram can be regenerated without inventing anything. A daily sync keeps the diagram and a generated architecture.md matching the ref, and both can be refreshed on demand or from an agent session.

What you give up is notation discipline. Datadef draws zones, nodes with real icons, and labelled edges. It does not enforce C4 levels, it does not validate that a component sits inside a container, and it will not stop someone from mixing altitudes on one canvas. If conformance is the requirement, that is a genuine loss.

Choose Structurizr when the deliverable is a model: when deployment views matter, when notation has to be defensible to an architecture board, when the DSL under review is the point. Choose generation when the actual complaint is that the picture is out of date and no one has time to fix it, which is the more common failure by a wide margin.

A useful test: open your current workspace and count the elements you cannot verify from the repository in under a minute. If that number is small, the model is healthy and Structurizr is doing its job. If it is large, you are maintaining fiction, and the fix is a source of truth that updates itself.

• IcePanel alternative
• Keep architecture docs in sync with code
• Repo to diagram: repository sync
• Datadef compared with PlantUML