整洁架构图解——依赖规则
整洁架构的工作原理，在一张交互式画布上讲清楚：实体、用例、接口适配器与框架，以及那条让内核保持独立的依赖规则。
整洁架构把代码组织成同心的若干层——实体、用例、接口适配器、框架——只服从一条规则：依赖永远指向内层，所以内核从不依赖任何工具。
整洁架构图解——依赖规则
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- 先自上而下读左边这一列的四层，从最内层的实体到最外层的框架。
- 再自上而下读右边这一列，那是管住它们的规则：依赖向内，适配器居中，内核不受触碰。
- 箭头虽然是从左往右画的，但它们在意义上是由外向内流动的——每一外层的代码都依赖它里面的那一层。
四个层
“实体——企业级业务规则”是最内层的那个圈：不管应用以什么方式交付都存在的对象和规则——一个客户、一张发票，以及一张发票不能被支付两次这条规则。“用例——特定于应用的规则”为某一个应用场景编排实体。“接口适配器——控制器、展示器”在用例和外部世界之间做翻译，而“框架与驱动——UI、数据库、Web”是最外面那一圈工具。
依赖规则
“依赖只能指向内层，绝不向外”正是这整套架构存在下来所要强制的那唯一一条规则：源代码依赖永远只向内穿越。“外层通过适配器对话，而不是直接找内核”是它的机制——一个用例声明一个用来保存发票的接口，由数据库适配器去实现，所以这个用例从不引入任何数据库类库。
回报
“更换框架而不必碰内核”和“内核从不引入任何框架”是检验规则有没有被守住的试金石：从一个数据库或一套 UI 迁移到另一个，实体和用例一点都不用改。这就是全部的价值主张——最重要、最昂贵的那部分代码，被隔离在最容易被替换的那部分之外。
Key relationships and takeaways
- 依赖永远指向内层——这一条规则就是这套架构本身。
- 内核声明接口，外面几圈去实现——适配器就是那道接缝。
- 实体和用例在构造上就与框架无关。
- 回报是可替换性：更换 UI、数据库或 Web 框架，都不必碰内核。
- 整洁架构讲的是依赖的方向，而不是层数的多少。
When to use this visual
- 在团队动手规划一个大代码库之前，先把依赖规则讲清楚。
- 评审一套架构：一个引入了 UI 或数据库类库的用例就是违规，而且在画布上看得见。
- 规划一次重写或迁移——画布显示哪些层必须留下来，哪些可以被替换。
运作方式
把各层改成你自己的技术栈
用你真实的名字替换这些通用的圈名——你的实体、你的用例类、你的控制器和网关、你实际使用的 UI 与数据库框架。
画出接口接缝
把内核声明的那些接口、以及每一个各由哪个适配器实现，都加上去，让图上记录下依赖规则所穿越的那些接缝。
标出违规的地方
给任何目前向外引入依赖的层加一个标签或换一种形状，并注明什么样的重构能修好它——画布同时也是一份审计。
演示一次真实的更换
加一条分支，让一个外层框架被另一个替换，两者都通过同一个适配器接入，最后落在毫无变化的内核上。
常见问题
什么是整洁架构？
它是一种由 Robert C. Martin 推广开来的架构模式，把代码组织成同心的若干层：中心是实体，往外是用例，再往外是接口适配器，边缘是框架与驱动。它的支配性规则是源代码依赖永远指向内层，所以核心业务规则从不依赖交付机制——UI、数据库或 Web 框架。
什么是依赖规则？
依赖规则说的是：源代码依赖必须永远向内穿越——外层可以依赖内层，反过来绝对不行。落到实践上，内层声明接口，外层去实现，所以内核的代码不会从边缘那些工具里引入任何东西。图上把这条规则画成一个独立的分组，因为这套架构其余的每一条性质都是从它推出来的。
整洁架构和分层架构有什么不同？
分层架构同样把职责分开，但它的依赖通常是自上而下流动的——表现层调用服务层，服务层调用数据层。整洁架构把这一点反了过来：业务内核坐在中心，其余一切都依赖它，所以依赖的方向才是那个区分特征。图上那支指向内核的箭头，正是这个差别被画了出来。
小项目值得用整洁架构吗？
并不总是——当业务规则很简单、或者团队只有一个人时，这套仪式的成本高过它的回报。只有当业务逻辑复杂到必须比工具活得更久，或者 UI、数据库很可能会变时，这个模式才值回票价。画布上那几个讲回报的方框把这笔交换说得很诚实：内核的安全，是用适配器层买来的。
在 QueryChart（FlowJam）中编辑这张图解
把上面这张整洁架构画布原样打开成你自己的图表，把各层改成你代码库里的名字，画出你自己的依赖。