DDD is easier to respect when you can see how the structure maps to folders and files: aggregates and entities in one place, application workflows next, then adapters, then HTTP at the edge. I wanted that map to be readable the same way you already browse code.
The page is a single static HTML build with a VS Code style layout: Explorer, editor tabs, C# snippets, a status line, and a right-hand panel that spells out what each file does and why it sits where it does in the DDD structure. If you want to poke at it yourself, you can view it live in the browser.
How the DDD structure shows up
The sample is labeled CleanArch.DDD, a .NET 8 layout where domain concepts stay in the center, use cases sit in Application, persistence and integrations live in Infrastructure, and the API project only speaks HTTP and wiring. Collapsible folders, tabs, and breadcrumbs are there so you can move the way you usually do when you open a new solution.
What the side panel adds
Each file you open comes with short notes, tags for patterns and tech, and optional dependency hints so you do not have to chase symbols across projects on day one.
The DDD shape is what the text keeps pointing back to:
- Domain holds entities, value objects, and aggregate rules, without infrastructure types mixed in.
- Application carries commands, handlers, and DTOs that describe use cases without leaking domain internals outward.
- Infrastructure covers EF Core, repositories, JWT, and anything that needs concrete libraries and configuration.
- API maps requests to application work and responses back out, with controllers and middleware kept thin.
Who it is for
If you already ship layered backends, it is a compact tour to share. If you are comparing how teams lay out DDD solutions, it is a guided path without unpacking a zip first. If you teach, the layout should feel familiar on a screen.
There is also a small “security kit” modal in the tool for the auth-related files, same idea with a tighter lens on tokens, hashing, and where secrets belong.
Closing
Good structure is mostly constraints made visible. I learn it faster when I can click the tree and read why each file exists. This playground is my shot at that.