整洁架构Clean Architecture分层

可视化演示

展示整洁架构四层同心圆结构、依赖反转原则DIP机制，以及与六边形/洋葱架构的对比，揭示分层架构的核心设计原则。

依赖规则

餐厅老板在后厨与前台之间画了一条看不见的“责任线”。前台想加新菜，不能直接闯进后厨改菜谱，只能把需求写成单子递进去；后厨做菜，也从不去研究客人用的是木筷还是银叉。整个餐厅只容许一件事自然发生：装饰、餐具、装修，都是围绕菜品而存在的，菜品从不迁就装修。

整洁架构把这条线叫做依赖规则（Dependency Rule）。它规定：源代码里的依赖关系，必须从外层指向内层。所谓外层，是靠近基础设施的东西；所谓内层，是靠近业务本质的东西。依赖永远不会反向，就像菜谱永远不会规定装修风格。

这条规则带来两个直接结果。第一，内层完全不认识外层：实体层的代码里不会出现 import 数据库驱动、不会出现框架注解。第二，外层可以自由更换：想换数据库、换 Web 框架，只要新外壳仍依赖内层定义的接口，内层纹丝不动。这也正是整洁架构让系统“可测试、可维护”的根源——测试时把外层替换成替身即可。

依赖规则的意义，就是那家老店的经营哲学：装修队换来换去，菜谱一页未动。把“会变的”和“不变的”分开，让变化止步于边界，让核心长治久安。

四层结构

一家餐厅能运转，靠的是四样东西：代代相传的菜谱、会做菜的厨师、传菜口与菜单翻译、以及墙上的装潢和桌上的餐具。这四样各司其职，缺一不可。整洁架构把系统也拆成对应的四层，由内向外依次为：实体层（Entities）、用例层（Use Cases）、接口适配器层（Interface Adapters）、框架与驱动层（Frameworks & Drivers）。

实体层封装最核心的业务规则，比如“订单金额等于单价乘以数量”“折扣不得超过五成”；它不关心数据存哪、页面长什么样。用例层编排一个个具体业务场景，比如“提交订单”要完成校验库存、计算金额、生成订单号——它像厨师按菜谱走完一道菜的流程，只认菜谱，不认客人。

接口适配器层负责翻译：把 HTTP 请求译成用例能懂的调用、把用例的返回值译成前端需要的 JSON，数据库的实现、消息队列的封装都在这一层。框架与驱动层则是壳：Spring、Django、数据库连接器、UI 组件，它们离业务最远，却最容易被替换。老板想换一批餐具，餐厅第二天就能换好。

四层结构最大的价值是“隔离”：菜谱不会因为餐厅换了两盏灯而改写。越往内越接近本质，越往外越接近噪音——这份隔离，让修改变得局部化、让替换变得低成本。

依赖反转

想换装潢很简单，但“让后厨不被某套餐具绑架”需要一条妙计：让所有想合作的前厅都按同一张“下单卡”来点菜，这张卡由后厨设计，前厅照着执行。餐具品牌可以换，但下单卡的格式是统一的——后厨定义了规则，而不是被规则定义。

这正是依赖反转原则（DIP, Dependency Inversion Principle）。传统写法里，高层用例直接依赖低层实现，比如用例直接调用 MySQLRepository；反转之后，用例依赖一个自己定义的接口（下单卡），数据库实现反过来依赖这个接口。依赖的源头被扭转了：不再是从上到下依赖细节，而是上下两层同时看向一个稳定的抽象。

关键点在于抽象接口的归属：接口必须归内层所有。外部世界不是“提供接口给你用”，而是“按照你定义的接口来实现”。于是控制权反转了——不是内层迁就外层，而是外层迎合内层。就像客户来餐厅吃饭，不是客人教厨师做菜，而是客人按菜单点菜，菜单由餐厅定。

所以“用了接口”不等于依赖反转，接口站在哪一边才是关键。接口属于内层，才是真正的“后厨说了算”。

架构关联

老店经营久了，老板发现别家店也用类似的法子：有人把餐厅搬进玻璃房子，四周通透，每个出入口都设一个传菜口；有人搭起洋葱般的帐篷，一层护着一层，越往里越神秘。这就是软件界两个著名的同类架构：六边形架构（Hexagonal Architecture）与洋葱架构（Onion Architecture）。

六边形架构强调“端口与适配器”：核心业务在中央，四周的端口定义对外能力，适配器把外部世界接进端口——好比玻璃房四面各设传菜口，任何方向的客人按同一规则点单。洋葱架构则画出一圈圈由内向外的依赖边界，依赖只允许从外圈指向内圈——好比帐篷的布料一层裹一层，你想碰到核心，得先穿过所有外层。

它们与整洁架构其实是同门师兄弟：都主张核心业务不依赖基础设施，都通过边界机制切断反向依赖，只是绘图方式与命名颗粒度不同。六边形重“端口适配”，洋葱重“层次包裹”，整洁架构重“分层加规则”——三者描述的是同一种世界观。下一次听到“我用的是洋葱架构所以不用整洁架构”，你就知道这说法站不住脚。

它们不是互相竞争的关系，而是同一理念的三张面孔。理解了这一点，读书、面试、选型时都能少一分纠结，多一分通透。

边界划分

传菜口是餐厅里最神奇的一扇门：食物只能从后厨端出去，点单纸却可以从外面递进来。门只有一个，东西却可以双向流动——但规矩只有一条：菜谱永远不许出门。软件系统的边界，正是这样的单向门。

数据流永远是双向的：点击“提交订单”，请求从外层（Controller）流入内层（用例层）；订单创建成功后，响应又从内层流向外层。但依赖流是单向的：永远从外层指向内层。我们可以说“边界”是数据双向穿行、依赖单向通行的门禁。

实践中，跨越边界时用接口作为“门框”。外层调用内层公开的接口，内层对外层一无所知；Java 里可能是 interface，Python 里可能是 ABC 抽象类，目的都是同一件事：让依赖在边界处止步。很多项目死在看似无关紧要的“穿透”上：实体直接序列化成数据库记录、用例层 throw 出 SQLException——边界一旦被穿透，菜谱就上了餐桌，看似方便，实则核心失守。

边界一旦守住，内外就能各自演进：内层专心业务，外层尽情折腾。门只有一扇，规矩只有一条——菜谱不离后厨，依赖永不外泄。

工程落地

老板决定开连锁店了。他把所有资源按职责分成四间库房：菜谱库、操作手册库、翻译工具库、装修物料库。项目结构一清二楚，任何新店照此复制就能开业。工程落地的第一步，就是这种“模块划分”。

对应到代码工程里，常见的划分是：domain 模块放实体与核心业务规则，application 模块放用例与内层接口定义，adapter 模块放接口的各类实现（数据库、消息队列、Web Controller），infrastructure 模块放框架配置与启动类。模块间的依赖方向严格沿 infrastructure → adapter → application → domain 单向流动，谁也不能反向引用。

实施顺序讲究“先内后外”：先写实体、再写用例、定义接口，最后接框架。就像先定菜谱、再定流程、最后选装修——而不是先订装修材料再倒推菜谱。测试时，外层全部用替身（mock/stub）代替，核心逻辑的单测不启动 Spring 容器、不连数据库，跑得飞快。落地不必一步到位，先在一个业务模块划出边界、打通依赖方向，再逐步推广到整个系统。

守住边界，架构自然会变得可维护；先内而外，系统才不会沦为“一堆框架的拼盘”。就像开分店，菜谱定好，装修随意换，家家都还是那家老店。

AI 应用场景

Python 演示

from abc import ABC, abstractmethodfrom dataclasses import dataclassfrom typing import List # 实体层: 领域核心对象, 不依赖任何框架@dataclassclass OrderItem:    name: str    price: float    quantity: int     def total(self) -> float:        return self.price * self.quantity @dataclassclass Order:    items: List[OrderItem] # 用例层: 编排业务场景, 只面向接口编程class CalculateOrderTotal:    def __init__(self, tax_provider):        self.tax_provider = tax_provider     def execute(self, order: Order) -> float:        subtotal = sum(item.total() for item in order.items)        tax_rate = self.tax_provider.get_rate()        return subtotal * (1 + tax_rate) # 接口适配器层: 接口归用例层所有, 外部实现它class TaxRateProvider(ABC):    @abstractmethod    def get_rate(self) -> float:        pass class SimpleTaxProvider(TaxRateProvider):    def get_rate(self) -> float:        return 0.06 class ZeroTaxProvider(TaxRateProvider):    def get_rate(self) -> float:        return 0.0 # 框架层: 组装所有组件, 提供运行入口def main():    order = Order([        OrderItem("coffee", 28, 2),        OrderItem("cake", 42, 1),    ])    app = CalculateOrderTotal(SimpleTaxProvider())    total = app.execute(order)    print(f"total: {total:.2f}") if __name__ == "__main__":    main()

1. class OrderItem实体层对象，把“单价×数量”这条业务规则收在领域内部，不掺任何数据库或框架代码。
2. class CalculateOrderTotal用例层，负责“计算订单总额”这一场景的编排，只认识接口不认识具体实现。
3. class TaxRateProvider(ABC)抽象接口定义在用例一侧，而非外部框架一侧，这正是依赖反转的关键。
4. class SimpleTaxProvider外层实现，随时可替换成别的税率策略，就像换一批餐具不影响菜谱。
5. CalculateOrderTotal(SimpleTaxProvider())在框架层完成组装，依赖通过构造函数注入，核心代码完全不感知具体策略。

常见误区

面试题