干净架构的同心圆依赖规则

干净架构（The Clean Architecture，由Robert C. Martin”Bob大叔”提出）用一组同心圆表达一种单向依赖关系，从逻辑上形成一种向上（向内）的抽象系统——圆圈越深入代表软件层次越高：外圆是战术实现机制，内圆是战略核心策略。让这套体系能工作的关键是”依赖规则”：源代码只能向内依赖，最里面的部分对外面一无所知（内部不依赖外部，外部依赖内部）——这条规则不仅约束代码名称、类的函数、变量这类命名实体的引用方向，也约束数据格式：外圈使用的数据格式不应该被内圈使用，尤其是当这些数据格式由外圈的框架生成时，绝不希望任何外圈层的变化会影响到内圈层。从外到内共四层：最外层是框架和驱动（数据库、Web框架等具体技术细节，这层不必写太多代码，主要写胶水代码与内层通信，所有实现细节都被隔离在这里，避免它们伤害业务规则）；往内是接口适配器（把用例和实体的数据转换成外部系统如数据库、Web所需的格式，GUI的MVC结构、各种视图控制器都属于这一层）；再往内是用例层（包含应用指定的业务规则，封装实现系统所有用例，混合来自实体的数据流程、指导实体运用企业规则完成用例目标——这层不该被更外层的数据库、UI或普通框架的变化影响，只有用例需求本身改变时该层代码才应该改变）；最内层是实体（封装企业业务规则，可以是带方法的对象，也可以是一系列数据结构和函数，只要能被不同应用程序复用即可——实体层不该被诸如”页面分页导航功能”或”安全机制”这类操作实现层面的改动影响，只有业务需求本身改变才能改变实体）。这套依赖规则带来四个独立性：独立于架构、独立于UI、独立于数据库、独立于任何外部类库——核心思想与分层架构中”底层不应依赖高层、两者都应依赖抽象”是相通的，都是通过强制单向依赖来减少耦合，区别在于干净架构把这个原则从”物理上下层”抽象成了”逻辑内外圈”，让”业务规则”而非”技术实现”成为被保护的核心。

结构图：

flowchart TD
    A["框架和驱动<br/>（数据库/Web框架等技术细节）"] --> B[接口适配器<br/>MVC/视图/控制器]
    B --> C["用例层<br/>应用特定业务规则"]
    C --> D["实体层<br/>企业核心业务规则<br/>（最内层，对外一无所知）"]