Clean Architecture: an editable mindmap

Clean Architecture: an editable mindmap

The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this mindmap

• Begin at “Clean Architecture” in the centre, then explore any branch that answers your question. The branch colors keep each group of ideas together.
• Curved lines show relationships; arrowheads appear only where one idea leads to another. Select any idea in the editor to change its text, position, or connections.

Business core

This branch brings together “The innermost circle: objects and rules that exist no matter how the app is delivered — a customer, an invoice, the rule that an invoice cannot be paid twice.”, “The core never imports a framework”.

Use cases

This branch brings together “Use cases orchestrate entities for one application scenario, such as “place an order”. They know about the app but nothing about screens or databases.”, “Because the database and UI are details, replacing them — a migration, a new front-end — leaves the entities and use cases untouched.”.

Adapters

This branch brings together “Adapters translate between the use cases and the outside world: an HTTP controller turns a request into a use-case call, a presenter turns results into a screen.”, “Outer layers talk through the adapter, not to the core”.

Frameworks

This branch brings together “The outermost ring: the tools. React, PostgreSQL, Express — details that can change without the core knowing or caring.”, “The dependency rule: source code dependencies always cross inward. The core declares what it needs (interfaces) and the outer rings implement them.”.

Connections across the map

Dependencies always point inward: that single rule is what the architecture is.

The core declares interfaces; the outer rings implement them: the adapter is the seam.

Entities and use cases are framework-independent by construction.

The payoff is replaceability: swap UI, database or web framework without touching the core.

Clean architecture is about dependency direction, not about the number of layers.

Key relationships and takeaways

• Dependencies always point inward: that single rule is what the architecture is.
• The core declares interfaces; the outer rings implement them: the adapter is the seam.
• Entities and use cases are framework-independent by construction.
• The payoff is replaceability: swap UI, database or web framework without touching the core.
• Clean architecture is about dependency direction, not about the number of layers.

When to use this visual

• Teaching the dependency rule to a team before they structure a large codebase.
• Reviewing an architecture: a use case that imports a UI or database library is a rule violation, visible on the canvas.
• Planning a rewrite or migration: the canvas shows which layers must survive and which can be replaced.

How it works

1. Start at the central topic

   Rename “Clean Architecture” if you want to adapt this map to a specific project or lesson.

2. Develop the branches

   Edit the supporting ideas, then add examples and notes where a branch needs more detail.

3. Connect related ideas

   Draw curved connections across branches; use an arrow only when the relationship has a direction.

Frequently asked questions

What is clean architecture?

It is an architectural pattern, popularised by Robert C. Martin, that organises code into concentric layers: entities at the centre, then use cases, then interface adapters, then frameworks and drivers at the edge. Its governing rule is that source code dependencies always point inward, so the core business rules never depend on the delivery mechanisms: UI, database, or web framework.

What is the dependency rule?

The dependency rule says source code dependencies must always cross inward: an outer layer may depend on an inner layer, never the reverse. Practically, the inner layers declare interfaces and the outer layers implement them, so the core's code imports nothing from the tools at the edge. The visual draws this as its own cluster because every other property of the architecture follows from it.

How is clean architecture different from layered architecture?

Layered architecture also separates responsibilities, but its dependencies usually flow top-down: the presentation layer calls the service layer, which calls the data layer. Clean architecture inverts that: the business core sits at the centre and everything else depends on it, so the direction of dependency is the distinguishing feature. The visual's arrow into the core is the difference made visible.

Is clean architecture worth it for a small project?

Not always: the ceremony costs more than it returns when the business rules are trivial or the team is one person. The pattern earns its keep when the business logic is complex enough that it must outlive the tools, or when the UI or database is likely to change. The canvas's payoff boxes state the trade honestly: the core's safety is bought with the adapter layers.

Edit this mindmap in QueryChart

Open this mindmap as your own editable free canvas. Move ideas, add branches, and draw new connections.

Edit this mindmap in QueryChart