Generate an architecture diagram from a Django project.
Django's conventions are strong enough that most of the architecture is declared rather than implied, which makes it one of the easiest sources to read accurately.
What it reads
settings for installed apps, databases, caches and configured third-party services; the URL configuration for the request surface; models for the data layer; and Celery task definitions for asynchronous work. Because Django puts each of these in a conventional place, there is far less inference here than in a framework where wiring happens at startup.
How Django becomes components
Each app is a component, which matches how Django projects are actually reasoned about. Models within an app become its data footprint, and foreign keys across apps become edges, which is the most useful output: cross-app model relationships are exactly where the boundaries that looked clean turn out not to be. Middleware and authentication backends form the request path, and third-party services in settings become external nodes.
Why the layout can be trusted
The agent reads the files listed above and emits a semantic graph: components, the tier each belongs to, and the edges between them, with no coordinates anywhere. The ELK layout engine then computes positions and orthogonal edge routing. This is why the output cannot come back with boxes overlapping or arrows crossing through cards, which is the usual failure when a language model is asked to place things on a canvas itself.
Two diagrams, not one
A Django project has an app architecture and an entity model, and they answer different questions. Drawing them separately keeps both readable, and the entity diagram in particular tends to be the one people keep, since a Django data model is where most of the domain lives.
Your code stays on your machine
It runs on your machine. With a local Ollama model nothing leaves the laptop at all, and with your own API key the file contents go to the provider you chose and never through us. For a source that is your actual codebase, that distinction is usually the deciding one.
Django to diagram
| In the project | In the diagram |
|---|---|
| INSTALLED_APPS | Components |
| urls.py | The request surface |
| models.py | Data tier and the entity model |
| Cross-app foreign keys | Edges between components |
| Celery tasks | Worker components |
| settings DATABASES and CACHES | Data tier nodes |
| Middleware and auth backends | The request path |
| Third-party service configuration | External nodes |
The prompt
Questions
Does it need the project to run?
No. It reads files, so it does not need a database, environment variables or a virtualenv.
Will it draw the entity model as well?
Yes, from the models, with cardinality read from the field definitions. It is usually worth generating as its own diagram rather than combining it with the app architecture.
Does it understand Django REST Framework?
Yes. Viewsets and routers read as the API surface, and serializers indicate which models are exposed, which is often more interesting than the model list itself.
What about multiple settings modules?
Point it at the one you care about. Diagramming a base settings module and a production override together mostly illustrates that they differ.
Related
- Generate a Diagram from a Next.js ProjectThe interesting line in a Next.js app is the one between server and client, and it is invisible in the file tree.
- Generate a Diagram from a Prisma SchemaA Prisma schema states relationships explicitly, which makes it one of the most reliable sources for an entity diagram that exists.
- Generate a Diagram from a CodebasePoint it at a repository and it surveys the code the way a new engineer would, then draws what it found.
- Generate a Diagram from TerraformTerraform already describes your infrastructure precisely. The diagram is a rendering of something you have written down, not a guess.
Last updated