三层架构诞生是为了给领域逻辑找一个安身之处

早期批处理系统直接操作特定文件格式（如ISAM、VSAM），没有分层概念，也不需要。20世纪90年代客户/服务器两层架构兴起，胖客户端工具（VB、PowerBuilder、Delphi）擅长把控件拖拽绑定到关系数据库，处理简单的数据展示和修改很顺手；但一旦出现领域逻辑（业务规则、验证、计算），要么塞进客户端——导致逻辑和界面耦合、跨界面的重复代码难以维护，要么塞进数据库存储过程——导致丧失SQL标准带来的数据库厂商可移植性。两条路都走不通，这才是三层架构（表现层/领域层/数据源层）真正被需要的原因：把领域逻辑从两端拽出来单独建模。Web的兴起进一步验证了这个分离的价值：分层良好的系统只需新增一个表现层就能把服务搬上Web，而把领域逻辑写死在胖客户端里的系统则必须整体重写才能上线。可迁移启发：判断要不要为某种逻辑单独抽出一层，看的不是”理论上是否更优雅”，而是”这块逻辑当前有没有无处安放，导致了重复代码或不必要的耦合”。