一、分层架构概述

什么是分层架构

分层架构，说白了就是把软件系统按照职责切分成若干层。每层只关心自己的事，层与层之间通过定义好的接口通信。

我刚开始做开发那会儿，见过一个项目把所有代码都塞在一个文件里。业务逻辑、数据库操作、界面渲染全混在一起。改一个功能，牵一发而动全身。后来重构成了三层架构，整个人都清爽了。

典型的层次结构长这样：

┌─────────────────┐
│   表现层         │  ← 用户界面、API 端点
├─────────────────┤
│   业务逻辑层     │  ← 核心业务规则
├─────────────────┤
│   数据访问层     │  ← 数据库操作、外部服务
└─────────────────┘

每一层只依赖它的下一层。表现层调用业务层，业务层调用数据层。反过来不行。这就是所谓的「单向依赖」原则。

分层架构的演进历史

分层架构不是一天建成的。我梳理了一下它的演进脉络，大致经历了这几个阶段：

时期	架构形态	特点
1960s-1970s	单体程序	所有代码揉在一起，没有分层概念
1980s	客户端-服务器	开始分离界面和数据处理
1990s	经典三层架构	表现层、业务层、数据层正式成型
2000s	多层分布式架构	引入服务层、缓存层、消息层等
2010s至今	微服务 + 分层	每个微服务内部仍保持分层结构

我记得最早接触分层架构是在学 Java EE 的时候。那时候的 JSP + Servlet + EJB 就是典型的三层。虽然现在看来那套东西太重了，但分层的思想一直没变。

为什么会从单体走向分层？说白了，软件越来越复杂。一个电商系统，你不可能把商品展示、订单处理、支付结算全写在一个模块里。不分层，后期维护就是噩梦。

分层架构的优点

我做了十几年开发，分层架构的好处，我总结了几点：

• 职责清晰：每层只做一件事。表现层只管展示，业务层只管规则，数据层只管存取。出了问题，定位很快。
• 易于维护：改表现层不用动业务逻辑。换数据库，只要改数据层就行。我在项目中遇到过，从 MySQL 迁移到 PostgreSQL，只改了数据层的代码，上层完全没动。
• 便于测试：每层可以独立测试。业务逻辑层可以 mock 掉数据层，用单元测试覆盖。不用启动数据库，跑得飞快。
• 支持并行开发：团队可以分工。前端写表现层，后端写业务层，DBA 管数据层。各干各的，互不干扰。
• 可扩展性强：需要加缓存？在业务层和数据层之间加个缓存层就行。不影响现有结构。

分层架构的缺点

没有银弹。分层架构也有它的短板：

• 性能损耗：每层调用都有开销。层数越多，性能越差。我曾经优化过一个系统，发现业务层和数据层之间来回传递对象，光序列化就占了 30% 的 CPU。
• 代码冗余：有时候一个简单的功能，要穿透好几层。明明只是查个用户信息，表现层要调业务层，业务层再调数据层。代码量翻倍。
• 过度设计：小项目硬套分层架构，反而增加复杂度。我见过一个只有三个页面的内部工具，硬是分了五层。维护起来比不分层还痛苦。
• 层间耦合：虽然说是分层，但层与层之间还是有依赖。业务层如果直接依赖了数据层的实现细节，换数据库时照样要改业务层。

什么时候该用分层架构

我个人的判断标准是这样的：

• 系统规模较大，超过 10 个功能模块 → 建议分层
• 团队超过 5 人 → 建议分层
• 业务逻辑复杂，规则经常变化 → 建议分层
• 需要长期维护（超过 1 年） → 建议分层
• 原型验证、小工具、脚本 → 不用分层，怎么快怎么来

你想想看，一个只有几百行代码的脚本，你给它分三层，那不是自找麻烦吗？

小结

分层架构是软件工程里最基础、最实用的架构模式之一。它不是什么高深的理论，而是无数前辈在实践中总结出来的经验。

嗯，这里要注意一点：分层不是目的，可维护性才是。别为了分层而分层。合适的才是最好的。

下一章，我会详细讲讲每一层的具体职责和设计要点。到时候我会结合我实际做过的项目，给你讲讲那些踩过的坑。