22 The Clean Architecture

近几十年出现了六边形架构（端口适配器）、DCI、BCE 等多种系统架构思想，虽细节有差异，但核心目标一致——关注点分离，均通过分层实现，至少包含业务规则层与用户/系统接口层，最终形成的系统具备共同特征：不依赖框架、可独立测试、UI 可替换、数据库可切换、与外部机构无关。

整洁架构以同心圆呈现层级，越向内软件层级、抽象度与策略层级越高，外层为机制、内层为策略，核心依赖规则是：源代码依赖只能向内指向更高层级策略，内层代码绝不能引用外层的类、函数、变量等命名实体，外层数据格式也不能影响内层。

• 实体（Entities）：封装企业级核心业务规则，是通用的业务对象，最不易受外部变更（页面、安全、数据库等）影响，可被企业内多个应用复用。
• 用例（Use Cases）：封装应用专属业务规则，实现系统所有用例，编排实体间数据流转并指挥实体执行业务规则；不受外部变更影响，但会随应用业务操作调整而改变。
• 接口适配器（Interface Adapters）：作为适配器，将数据在内外层格式间转换，包含 MVC 各组件、数据库适配代码、外部服务适配代码，SQL 仅局限于此层，内层无需知晓数据库细节。
• 框架与驱动程序（Frameworks and Drivers）：最外层，由数据库、Web 框架等工具组成，仅编写与内层通信的胶水代码，Web、数据库等技术细节均放在此层，降低对核心业务的影响。

架构层级不局限四层，可按需增加，但依赖规则始终不变，越向内抽象度与策略层级越高。跨层级交互需遵循依赖反转原则，通过接口与多态让源码依赖逆着控制流指向内层；跨边界传递的数据为简单独立的数据结构（DTO、结构体、函数参数等），格式以内层便利为准，禁止传递实体对象或外层数据库行结构，避免违反依赖规则。

以 Web+数据库的 Java 系统为例：Web 服务器收集数据交给控制器，控制器封装为普通对象经输入边界传给用例交互器，用例指挥实体并通过数据访问接口从数据库获取数据，执行后将结果封装为输出数据，经输出边界传给呈现器；呈现器将其转为视图模型（格式化后的字符串、标识等），视图仅需将视图模型渲染为 HTML 即可，所有依赖均向内指向核心。

遵循分层与依赖规则，可构建天生可测试的系统，当数据库、Web 框架等外部组件过时，能以最小成本替换，大幅降低系统维护与迭代的麻烦。****