整洁架构图解——依赖规则 · 思维导图

整洁架构图解——依赖规则. 可编辑的思维导图,以彩色分支、子主题和曲线连接呈现想法。 曲线表示联系;只有方向重要时才使用箭头。

整洁架构把代码组织成同心的若干层——实体、用例、接口适配器、框架——只服从一条规则:依赖永远指向内层,所以内核从不依赖任何工具。

整洁架构图解——依赖规则 · 思维导图

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

如何阅读这张思维导图

  • 从中心主题开始,沿着彩色分支探索相关想法。
  • 曲线表示联系;只有方向重要时才使用箭头。

Business core

这一分支汇集 “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

这一分支汇集 “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

这一分支汇集 “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

这一分支汇集 “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.”.

跨分支联系

依赖永远指向内层——这一条规则就是这套架构本身。

内核声明接口,外面几圈去实现——适配器就是那道接缝。

实体和用例在构造上就与框架无关。

回报是可替换性:更换 UI、数据库或 Web 框架,都不必碰内核。

整洁架构讲的是依赖的方向,而不是层数的多少。

Key relationships and takeaways

  • 依赖永远指向内层——这一条规则就是这套架构本身。
  • 内核声明接口,外面几圈去实现——适配器就是那道接缝。
  • 实体和用例在构造上就与框架无关。
  • 回报是可替换性:更换 UI、数据库或 Web 框架,都不必碰内核。
  • 整洁架构讲的是依赖的方向,而不是层数的多少。

When to use this visual

  • 在团队动手规划一个大代码库之前,先把依赖规则讲清楚。
  • 评审一套架构:一个引入了 UI 或数据库类库的用例就是违规,而且在画布上看得见。
  • 规划一次重写或迁移——画布显示哪些层必须留下来,哪些可以被替换。

运作方式

  1. 调整中心主题

    根据项目或课程修改中心主题的名称。

  2. 扩展分支

    编辑想法并添加示例或注释。

  3. 连接相关想法

    绘制跨分支连接;只有方向重要时才使用箭头。

常见问题

什么是整洁架构?

它是一种由 Robert C. Martin 推广开来的架构模式,把代码组织成同心的若干层:中心是实体,往外是用例,再往外是接口适配器,边缘是框架与驱动。它的支配性规则是源代码依赖永远指向内层,所以核心业务规则从不依赖交付机制——UI、数据库或 Web 框架。

什么是依赖规则?

依赖规则说的是:源代码依赖必须永远向内穿越——外层可以依赖内层,反过来绝对不行。落到实践上,内层声明接口,外层去实现,所以内核的代码不会从边缘那些工具里引入任何东西。图上把这条规则画成一个独立的分组,因为这套架构其余的每一条性质都是从它推出来的。

整洁架构和分层架构有什么不同?

分层架构同样把职责分开,但它的依赖通常是自上而下流动的——表现层调用服务层,服务层调用数据层。整洁架构把这一点反了过来:业务内核坐在中心,其余一切都依赖它,所以依赖的方向才是那个区分特征。图上那支指向内核的箭头,正是这个差别被画了出来。

小项目值得用整洁架构吗?

并不总是——当业务规则很简单、或者团队只有一个人时,这套仪式的成本高过它的回报。只有当业务逻辑复杂到必须比工具活得更久,或者 UI、数据库很可能会变时,这个模式才值回票价。画布上那几个讲回报的方框把这笔交换说得很诚实:内核的安全,是用适配器层买来的。

在 QueryChart 中编辑此思维导图

在可编辑画布中打开思维导图。移动想法、添加分支并绘制连接。

在 QueryChart 中编辑此思维导图

思维导图中的更多内容