分层架构演进

用途：理解各种分层风格从何而来、各自解决什么问题

演进主线

阶段	形态	解决的问题	遗留问题
1	单体一段式脚本	快速实现	无结构，规模一大即失控
2	三层（表现/业务/数据）	代码归类、职责初分	依赖方向可反向渗透，业务层依赖 SQL 细节
3	四层（+ 领域层）	业务规则集中、可测试	仍可能出现领域层依赖基础设施
4	依赖倒置（端口在内部）	领域层不依赖技术细节	端口/适配器概念未显式化
5	六边形 / 洋葱 / 整洁架构	显式化“核心与外围”，适配器可替换	小系统过度设计的风险
6	组件化与模块化单体	在单进程内固化模块边界	需要构建期约束支撑
7	微服务	独立部署与团队自治	分布式复杂度、数据一致性

依赖指向稳定的一侧：业务规则最稳定，技术细节最易变，因此代码依赖必须从技术细节指向业务规则，而不是相反。Robert C. Martin 的依赖规则（源码依赖只能朝内）是同一件事的不同表述。

层数的意义只在一个地方：让“改哪里不影响哪里”成为可验证的事实。如果加了层却没有约束依赖方向，分层只是目录结构。

反过来，如果模块本身极简（配置管理、字典维护），三层以内完全合理——按子域价值分级投入。

分层是代码结构问题，微服务是部署与组织问题，两者正交：单体可以有漂亮的分层，微服务也可能每层都混乱。先解决结构，再决定部署粒度，是更稳的顺序。