整洁架构是什么
整洁架构用一条依赖规则组织代码：源码依赖只能指向内层，越内层越稳定、越抽象，越外层越具体。典型层次是实体、用例、接口适配器、框架与驱动，用例承载应用逻辑，数据库、Web 框架与消息中间件都属于可替换的外部细节。它带来的直接收益是业务规则可以脱离框架测试，外部实现更换时业务代码不需要改动。
基本信息
| 依赖规则 | 源码依赖只指向内层，跨边界用接口与数据模型转换 |
|---|---|
| 层示意 | 实体 → 用例 → 接口适配器 → 框架与驱动 |
| 收益 | 业务规则可独立测试，外部实现可替换 |
| 与六边形关系 | 表达同一依赖规则的另一种图形，术语不同规则一致 |
| 落地单位 | 通常以业务用例或模块为单位应用，而非整个系统统一模板 |
落地要点
- 依赖方向：内层不出现框架、ORM 与 HTTP 类型
- 边界转换：跨层传递用本层模型，不透传框架实体
- 用例独立：用例可脱离交付机制单独测试
- 目录适度：不追求固定四层目录，按依赖规则验证
- 检查自动化：构建期用依赖分析工具拦截违规引用
常见偏离与影响
| 偏离 | 表现 | 影响 |
|---|---|---|
| 内层依赖框架 | 实体带 ORM 注解 | 无法脱离数据库做单元测试 |
| 边界不透传转换 | 控制器直接传框架实体到用例 | 外部结构变化冲击业务逻辑 |
| 用例层写业务规则 | 规则集中在用例类中 | 跨用例复用困难，规则重复 |
| 层数过多 | 每层只做透传 | 调用链变长，理解成本上升 |
整洁架构与领域驱动设计的组合很自然：实体与聚合属于最内层，应用服务承载用例，适配器承担技术细节，二者术语可以对应理解。
落地时避免把“层”做成固定目录模板，重点是依赖方向与边界数据模型转换，形式统一并不能替代依赖校验。