三层架构实战演进：数据访问层设计与多数据库踩坑总结

1. 从一场折腾了三天的重构说起

“三层架构”这四个字，几乎每个做后端开发的人都被耳提面命过。教科书上说，表现层、业务层、数据访问层，各司其职，层次清晰，好像只要照着画分层图就能写出优雅的系统。但真到了实战里，你会发现事情完全不是这样：业务逻辑到底放哪一层？数据访问层是直接写SQL还是套一层ORM？中间层要不要给每个模块都画接口？多数据库并存的时候，数据访问层该怎么设计？这些问题，教科书上不会给你答案，只有踩过坑才能摸到门道。

我写“架构经验小结”这个系列，就是想把这些实战里摸出来的东西沉淀下来。这一篇聊的，是我们在一个实际项目里一步步演化出来的三层架构。这个项目早期就是个典型的单体应用，随着业务复杂度上来、团队人越来越多、数据库从一套变成两套，原本简单粗暴的结构撑不住了，才逼着我们不停地调整边界、抽离职责、引入抽象。整个过程没有一次性的“架构设计”，全是需求倒逼出来的演进。这篇文章不聊高大上的分布式微服务，就聊一个普通的业务系统，在三层架构这条路上，到底是怎么一步一步走到成熟形态的。

如果你正准备给项目搭架构，或者已经被现有代码的分层混乱折磨得睡不着觉，这篇东西应该能给你一些可以直接落地的思路和避坑参考。

2. 为什么要分层，以及为什么最后还是三层

2.1 不分层的日子是怎么把人逼疯的

最早我们这个项目也谈不上什么架构。数据库有一张表，业务代码里就直接拼接SQL去查；用户要加一个字段，先改数据库，再满代码里找那个字段名全局替换。听起来好像也能跑，但项目到五万行代码的时候，整个人的精神状态就不对了。

典型的问题有三个。第一，改一个业务规则要动好几个文件，而且经常漏改，因为同样的规则散落在不同的入口里。比如计算订单金额那段逻辑，列表页要算一次，详情页又要算一次，后台管理还要算一次——三处代码各自实现，一旦折扣规则变了，漏改一个地方就出线上事故。第二，测试根本没法写，所有逻辑都依赖数据库状态和HTTP请求上下文，想跑一个单元测试得先搭一整套环境。第三，新人来了根本看不懂代码，没人说得清一个请求从进来到落库，中间到底经过了哪些步骤。

这三个问题本质上指向同一个根因：代码缺乏明确的责任边界。数据怎么存取、业务怎么处理、结果怎么展示，全都混在一个大泥球里。这时候不是要不要分层的问题，是不分层已经活不下去了。

2.2 分层带来的核心收益，不只是“好看”

分层这件事，最早是为了解决“变化传导”的问题。打个比方，如果整个系统是一栋楼，不分层就相当于承重墙和隔断墙没有区别，你想挪一面隔断墙，发现整栋楼都跟着晃。而分层之后，表现层、业务层、数据访问层各自有了独立的“承重结构”，改其中一层的内部实现，只要接口不变，其他层不该感知到变化。

这个收益在实战里是有直接体现的。我们后来做数据库从一套切换到另一套的时候，因为数据访问层被完整地隔离出来了，整个切换过程没有动过一行业务代码，只替换了数据访问层内部的实现和配置，三天就完成了灰度迁移。如果还是早期那种把SQL散落在业务代码里的写法，这种切换基本等于重写系统。

所以分层的本质，不是让代码结构看起来更规范，而是给系统的变化点划定缓冲区。你把变化限制在一个可以被替换、被测试、被忽略的区域内，系统整体的稳定性就上来了。

3. 从“两个Layer”到“三个Layer”的演化路径

3.1 演化起点：最初的“展示+存储”两层结构

看这个项目的演进过程，最开始其实只有两个Layer。一个负责接收请求、拼HTML、render页面，另一个负责直接读写数据库。中间找不到一个地方放业务规则，于是业务代码只能“寄生”在表现层里——本来该做输入校验的地方，顺便把折扣算了；本来该格式化展示的地方，顺便把状态机流转写了。

这种结构的直接后果，是表现层越来越臃肿。一个Controller方法可以写到几百行，前半段在解析参数，中间一大段全是业务逻辑，最后才拼接返回结果。而且因为业务逻辑和HTTP协议绑在一起，同一个规则没法在命令行脚本、定时任务、消息队列里复用。我们后来要加一个异步任务来批量处理订单，发现只能把Controller里的代码复制一份改改——这就是明显的坏味道，但当时也只能这么干。

这算是三层架构演化的第一个关键转折点：当业务逻辑需要在多种入口之间复用时，就必须从表现层里独立出来。

3.2 中间层不是“加一个文件夹”那么简单

很多团队也意识到了要加中间层，但落地方式往往是在工程里新建一个目录叫“Service”，然后把原来写在Controller里的代码整体搬过去。这么做表面上从两层变成三层了，实际上只是把“臃肿”从表现层挪到了业务层，没有解决任何结构性问题。

真正的中间层设计，需要想清楚三件事：

• 编排职责：业务层是“调度中心”，负责编排多个数据操作、调用外部服务、执行业务规则，但不该直接拼SQL、不该关心HTTP请求长什么样。
• 事务边界：一个业务用例对应一个业务层方法，事务在这个方法上开启和提交，这样才能保证多个数据操作要么都成功、要么都回滚。
• 复用粒度：业务层方法的粒度要匹配真实的业务操作，而不是匹配数据表的操作。用“下单”而不是“插入订单表+更新库存表+插入流水表”这种拆散了的细粒度方法。

当时我们把订单相关的业务从Controller里抽出来的时候，就定了这么一个大原则：Controller只做“翻译”（把HTTP参数翻译成业务层输入，把业务层结果翻译成HTTP响应），一切商业规则都只住在业务层。这套原则一直沿用到现在，没有再出现业务逻辑外泄到表现层的情况。

3.3 数据访问层不是越薄越好

数据访问层这个问题，跟业务层刚好相反，它是太薄了不行，太厚了也不行。

太薄的典型情况，就是只做一件事：把业务层传来的参数拼进SQL里，然后执行并返回结果。看起来干净利落，但所有跟数据存储相关的复杂性都暴露给了业务层——业务层得知道“这个查询要走索引A所以条件顺序不能变”“这个表是分片的所以查询必须带上分区键”，这些本质上是存储细节，不该让上层操心。

太厚的情况则是另一种极端：把大量的关联查询、报表统计、复杂运算逻辑全都怼进数据访问层里，结果数据访问层变成了一个“什么都会”的超级类，业务层调用它的时候，根本不知道该传哪些参数、该期待什么返回。

实战里相对健康的形态，是数据访问层负责“数据的进出”，并在接口形态上匹配业务层的需要，而不是匹配表结构。比如说，业务层需要一个“用户及其最近三笔订单”的聚合数据，数据访问层就该提供一个返回这个聚合形态的方法，而不是暴露两个方法让业务层自己去join。

4. 数据访问层设计中最花钱的三个决策

4.1 要不要引入ORM，以及引入到什么程度

数据访问层设计的第一个分歧点，就是ORM的选型和用法。这个项目早期用的是原生SQL，后来为了提升开发效率引入了一个轻量级ORM，但引入了之后发现，滥用ORM的坑远比写SQL的坑多。

核心问题在于，ORM把“关系模型”和“对象模型”做了映射，但映射是有损的。复杂的join查询、动态条件组合、批量更新，在ORM里的表达往往很别扭，生成出来的SQL可能跟数据库优化器期望的执行计划完全相反。这是我们踩得很痛的一个坑：一段看起来人畜无害的ORM链式调用，实际生成的SQL带了全表扫描加逐行子查询，一条本来该30毫秒返回的接口，硬生生跑到了两秒多。

后来我们定了一个标准：简单的单表CRUD，走ORM；任何涉及多表join、聚合统计、复杂条件查询的，直接写SQL。而且这些SQL不是散落在业务层代码里的字符串，而是集中放在Repository里，用专门的目录维护。这样既保住了开发效率，又保住了查询性能和可优化空间。

4.2 中间层要不要为每个模块都抽象接口

这是一个被讨论过无数次的问题，也是团队里吵得最凶的问题之一。要不要给业务层接口？要不要给数据访问层接口？写实现类的时候要不要通过依赖注入接到上层？

在真正的实践里，经验是：不要为了抽象而抽象，要在看到真实的替换需求后再动手。如果一个数据访问层实现只有一个数据库、一种实现方式，且短期内看不到第二种实现方式的可能，强行拆接口只会增加代码跳转的复杂度——你从一个方法跳到实现，要经过一层接口才知道真正执行逻辑在哪，这对阅读代码的负担是很大的。

我们当时真正引入接口，是因为出现了“多数据库并存”的硬需求。主库是一套OLTP的数据库，后来又引入了一套用于分析查询的列式存储数据库。同一个业务数据要从两套库里查询，业务层不想关心数据到底来自哪个库，这时候在数据访问层抽一个接口，提供两个实现，才是真正的“被需要”。所以接口的引入不是架构规划的结果，而是多重实现出现之后，代码层面被迫收敛的产物。

4.3 缓存到底放在哪一层

缓存的位置这件事，很多团队的架构图里是画不清的。有的把缓存逻辑写在业务层，有的写在数据访问层，代码一旦多起来，同一份数据的缓存散落得到处都是，失效规则能混乱到让人崩溃。

我们的经验是：缓存应该被视为数据访问层的一部分。因为缓存的本质，是数据存取链路中的一个优化环节，它管理的是“数据怎么读得快”，而不是“业务规则怎么执行”。把缓存放在业务层，会导致业务逻辑里夹杂着“先查缓存，没命中再查库，回填缓存”这种基础设施性质的动作，属实喧宾夺主。

更好的做法是，在数据访问层内部封装一个“带缓存的Repository”。业务层调用的时候感知不到缓存的存在，它只知道自己调了一个查订单的方法，方法返回了数据。缓存键怎么设计、过期策略怎么定、缓存和数据库的一致性怎么保证，这些全部收拢在数据访问层内部解决。这个调整做下来，缓存接口的调用量降了将近一半，因为以前业务层手忙脚乱地重复铺设缓存逻辑，现在一个请求只会在真正需要的时候走到缓存动作。

4.4 数据模型该不该跟着数据库表走

这是数据访问层设计里最隐蔽的一个问题：业务层拿到的数据模型，到底应该长什么样？很多团队直接用数据库表的实体类作为业务层的数据模型，表面上看省了很多转换代码，但坑在后面等着。

最典型的情况是，一张表在数据库里有二十多个字段，其中有一半是系统字段（创建人、创建时间、更新人、更新时间、版本号、逻辑删除标记），另一半才是业务真正关心的。如果这些字段全量传到一个业务层方法里，调用方根本分不清哪些字段是允许修改的、哪些字段只是查询条件。更麻烦的是，当业务层需要的是一个跨表的聚合数据（比如“订单+商品+店铺”的组合视图），直接用表实体类根本无法表达这种形态。

后来我们做了一个看来“多此一举”的调整：为业务层定义专门的数据模型（DTO/VO），不直接从数据库实体类透传。虽然每次写数据访问层的映射代码会多一些工作量，但这层映射换来的是业务层代码的可读性和安全性——调用方一眼就能看出来这个方法的入参是什么语义，不会看到二十个字段一头雾水。从维护成本看，这个投入是非常划算的。

5. 三层架构在“多数据库并存”挑战下的实战演进

5.1 项目里真实的“多数据库”是从哪来的

很多人一听到“多数据库”就联想到分布式、分库分表那些大场面。实际上，我们这个项目的多数据库切换需求非常朴素：业务增长之后，线上主库的压力越来越大，数据查询分析的需求也越来越重，于是我们引入了一套独立的统计数据库，把规模较大的只读查询和报表需求分流过去。主库负责交易类写入和实时性要求高的查询，统计库负责大数据量、低实时性的聚合分析。

这套双子库的构型如果架构设计不到位，会直接把团队拖进双重维护的泥潭——同一个查询逻辑要写两套实现，且两套实现之间的一致性很难保证。我们的解法是靠“数据访问层抽象”来隔离这种变化：业务层完全不知道自己到底在读哪个库，它只感知到“我调用了一个方法，得到了一堆数据”，至于这些数据来自主库还是统计库，是数据访问层内部根据查询类型在决定。

5.2 多数据源连接管理里的那些细节

多数据源接入以后，第一波麻烦就出现在连接管理上。Spring的DataSource不是无限创建的，每个数据源都有连接池；连接池的参数（初始连接数、最大连接数、空闲连接回收时间）如果不分开配置，两个库共享一个池，一旦统计库有慢查询把连接池占满，主库的正常交易也会被拖死，这属于典型的“故障隔离没做好”。

我们当时把数据源配置拆开了，主库和统计库各自独立的连接池参数。统计库因为查询量大但并发不高，最大连接数设置得保守一些；主库要支撑写事务，连接数和超时设置相对宽裕。更重要的是，所有数据源的切换都收在数据访问层的内部，上层的业务代码根本感知不到数据源的存在。

5.3 多数据库下的脚本管理与版本控制

多数据库第一个容易露馅的环节，是建表脚本的同步。项目早期用一套SQL脚本维护表结构，引入统计库之后，脚本数量直接翻倍。很多团队会遇到这种千古难题：开发环境用A脚本建表，测试环境又用B脚本建表，生产环境部署的时候C脚本才被拉出来跑，版本根本对不上。

我们的应对方式，是把数据库脚本也纳入同样的依赖管理流程。每个数据库一个独立目录，每个脚本带版本号，从版本基线开始连续递增，应用启动时有专门的模块比对脚本版本和执行差异。这套机制现在看来平平无奇，但当时没有这套机制的时候，环境不一致导致的问题排查成本，远超写脚本本身的时间。

6. 业务层里最微妙的那个分寸：规则放哪

6.1 事务脚本模式在中小型项目里的合理性

业务层一旦独立出来，就会面对下一个问题：业务逻辑怎么写才算“好”？我见过不少团队一头扎进“领域模型”的汪洋大海里，各种Domain Service、Factory、Specification满天飞，结果代码抽象层次太高，团队里能看懂的人没几个。

这里要先明确一点：如果业务就是“输入参数→处理→落库”这种典型的流水线式操作，事务脚本模式就足够了。事务脚本的核心思路，是“一个业务用例对应一个方法，方法内部依次完成校验、计算、数据存取”。代码直白、好测、好维护，没有任何复杂的对象关系网。我们在项目早期大量使用这种写法，业务的开发速度非常快。

这种模式的地雷在于，如果不对“脚本”之间的重叠逻辑做收敛，就会发展成坏的复制粘贴文化。案例就是优惠计算逻辑被复制到下单、退款、后台改价三个地方。好在我们后来做了收敛，把这类共享规则抽成了独立的业务组件，三个入口共用同一个实现，问题才算根治。

6.2 什么时候值得把富血模型请进来

随着业务复杂度的上升，有一部分核心域的“脚本”会变得越来越难维护——一个方法里塞了十几个if-else分支，每种分支组合对应不同的状态流转和校验规则，事务脚本写到这里，方法体已经膨胀到没办法读了。

这就是从“事务脚本”演进到“领域模型”的信号。富血模型的做法，是把行为和数据绑在一起：订单不仅仅是拥有状态字段，它还知道怎么自己变更状态、校验当前状态是否能执行某个操作、计算自己的金额。业务层方法变得很薄，只是调用“订单对象”的方法来完成操作。

但要注意，领域模型的引入有前置条件：团队对领域术语有共识，并且核心域是稳定的。如果业务规则三天两头在变，今天订单可以这样流转，明天又要加一个中间态，那模型设计出来很快就会因为频繁改动而腐烂。我们当时没有对整个系统做领域建模，只挑了一个规则最复杂、变化最少的核心域做了局部落地，起到了示范效果，也不至于把整个项目拖进重度设计过度的泥坑。

6.3 业务层和数据访问层之间的“事务边界”之争

业务层和数据访问层之间，最常打架的地方是事务边界。很多团队习惯在数据访问层的方法上加事务注解，这会导致一个严重后果：当业务层一个用例需要连续调用多个数据访问方法时，每个方法各自开一个事务，中间任何一个失败，之前已执行的数据库操作不会回滚，数据一致性直接GG。

正确的做法是，事务的边界应该开在业务层。每一个业务用例对应一次事务，业务层方法内的所有数据操作在同一个事务里执行，统一提交或回滚。我们为了确保这个规则被遵守，立了一个约定：业务层方法是事务的唯一边界，数据访问层的所有写操作方法不允许自行开启事务。这个约定通过代码评审来强制落地，效果一直很好。

7. 表现层的边界：Controller不背业务的锅

7.1 Controller只做翻译，不做判断

三层架构里，表现层是最容易被低估的一层。很多Controller被当成了“万能入口”，什么参数校验、业务逻辑、数据组装都往里面塞，等回头想抽离的时候已经骑虎难下。

我们当时的自我约束是：Controller只允许做三件事——解析HTTP参数、调用单个业务层方法、把返回结果翻译成HTTP响应。除此之外的一切，都不许出现在Controller里。这套约束刚落地的时候，很多同事不习惯，觉得明明一行代码就能在Controller里调个服务，为什么非得绕一圈到业务层。但坚持一段时间之后，大家发现好处非常明显：代码review的时候，只看Controller就能判断输入的参数有没有被正确处理；业务规则的调整完全不用碰Controller，测试也好写了很多。

7.2 参数校验到底放前台还是放后台

还有一个老生常谈的问题：参数校验放哪？我们的标准是分两层。第一层是“格式校验”，比如必填字段、类型、长度、格式，这部分放在Controller层，用轻量级的校验框架快速拦截非法输入；第二层是“业务校验”，比如“该用户是否具备下单资格”“库存是否足够”，这部分放在业务层，因为这种校验依赖的是数据状态，属于业务规则的一部分。

如果只做格式校验而不做业务校验，会出现一个经典事故：一个请求通过了格式校验，进了业务层，却发现这个用户的账户已经被冻结了，但业务层的代码不检查，直接把订单创建了。这个坑，我们踩过，代价是赔了一单全额退款。从那以后，“业务校验必须在业务层执行”就成了硬性要求。

7.3 返回结果不要再裸奔，统一包装一下

很多系统的接口返回结果是supposed“Entity直接序列化”，这种做法在项目初期看起来没什么问题，但一旦前端需要统一的响应格式、错误码、分页结构时，改动量能把人折腾疯。

我们把返回结果统一封装成一个标准结构：状态码、提示信息、业务数据、幂等标识（可选）。所有Controller方法都返回这个结构，前端只用解析一种格式。这个调整看起来是表现层的小事，但对前后端联调效率的提升非常可观，因为前端再也不用为“这个接口返回的到底是数组还是对象”这种事反复跟后端确认了。

8. 实战里最常见的问题排查与踩坑经验

8.1 数据库切不动：脚本、枚举、人员和权限的连环套

我们切换统计库的那一次，本以为只要把数据访问层的连接池指向新库就行，结果在灰度过程中出了不少问题。

第一个坑是表结构不兼容。统计库因为要支持高性能聚合查询，刻意对某些表做了字段类型调整，比如把字符串类型改成了枚举类型、把普通索引换成了覆盖索引。结果业务层传来一个字符串，统计库直接不认，整条链路报错。

第二个坑是权限配置遗漏。从主库复制了一个只读账号到统计库，但漏配了两个表的查询权限，灰度刚开始就开始报错，回滚又花了不少时间。

第三个坑是团队里的历史包袱。一些老的SQL脚本里写死了主库的表名，切到统计库之后表名对不上，花了整整一天排查。

这些坑总结成一句话：多数据源切换，技术方案只占一半，另一半是数据本身的兼容性、权限、脚本这些配合项。方案再好，这些细碎的配套不齐，一样会翻车。

8.2 缓存和数据库的一致性，比想象中更麻烦

缓存一致性这问题，教科书里给了很多高深的方案，实战里我们用的其实是最务实的一种：Cache-Aside，也就是读的时候先读缓存，读不到再读数据库并回填；写的时候先更新数据库，再让缓存失效。

这个方案看起来简单，但执行细节里暗藏杀机。比如缓存失效的操作，必须是“先更新库再删缓存”，而不是“先删缓存再更新库”。为什么？因为如果先删了缓存，紧接着业务层读请求把旧数据回填到缓存里，然后数据库才完成更新，缓存里永远都是旧值。反过来，先更新数据库再删缓存，哪怕在更新完成之后删缓存之前有读请求进来，读到的还是旧值，但缓存马上被删掉，下一次读就会重新从库里取到新值，不一致的时间窗口非常短。

还有一个细节是，缓存的key设计不好也会踩大坑，比如直接把整个对象序列化成一个key，结果每次修改其中一个字段都要把整个缓存失效，大对象的序列化成本反而成了瓶颈。后来的经验是，大对象拆分成字段级粒度的缓存，各管各的，效果更好。

8.3 性能问题的根因，往往不在代码，而在数据访问层

我们在排查一个深夜线上的性能问题时，花了很长时间复查业务层的代码，最后才发现问题出在数据访问层——一个列表查询接口，业务层调用了一次“查询订单列表”，数据访问层为了拼接“订单+商品名称+店铺名称”，在循环里逐个执行了二次查询，导致一个本该跑一次SQL的接口变成了1加N次查询。

数据访问层最容易出现性能问题的地方不在SQL本身，而在“拿数据的方式”。ORM的懒加载机制、循环里的逐条查询、没有合理利用批量查询，这些才是隐形杀手。后来我们立了一条军规：数据访问层的方法里不允许出现循环内查询，所有需要在大量数据上装配的场景，一律用批量查询一次拉出来，再在内存里做装配。这条军规立下来之后，数据访问层的性能问题大幅减少。

8.4 小问题速查：一张表里看三层架构的四大常见事故

下面是我们在多轮实战里沉淀的经验要点，遇到同类问题可以直接对照。

9. 团队协作模式下的“架构落地”心得

9.1 架构不是画完图就完事，得让每个人都认同边界

三层架构在理论上很容易讲清楚，但真正落地的时候，最难的从来不是设计，而是团队的执行一致性。再好的分层设计，如果代码评审不把关、新人不培训、约定不沉淀成文档，过不了三个月就会退化成一个大泥球。

我们的做法是双轨并行：一是在代码评审的时候，专门检查“职责边界”，看到Controller里出现业务逻辑就直接打回，看到数据访问层里出现业务规则也打回；二是把分层约定写成一份简短的内部规范，但规范内容不是泛泛而谈“高内聚低耦合”这种原则，而是落到“什么能出现在Controller里”“事务边界在哪”“数据访问层的方法命名规则是什么”这种可操作的条款。

9.2 新人上手成本，是架构好坏的一个隐形指标

架构设计得好不好，有一个经验指标是“新人上手速度”。好的分层架构，新人进项目之后，通过代码结构就能大致推测出“查数据应该去哪看”“改业务应该去哪找”，不需要靠老同事口口相传才能找到代码位置。

我们后来有个很有意思的验证：让一个刚入职的实习生独立完成一个中等复杂度的需求，他在没有看过任何架构说明文档的情况下，凭代码目录结构自己找到了该改的类、该加的方法，独立完成了开发。这个案例说明，分层的边界如果是清晰的，代码本身就是最好的文档。反过来，如果新人在代码里迷路了，四处找不到在哪里改，那很可能不是新人的问题，是架构的边界设计出了偏差。

10. 写在最后的几点个人体会

做架构这些年的实际感受是，三层架构不是一道“设计题”，而是一道“演化题”。它不是在项目启动第一天就可以一锤定音的——真正的设计，是在业务复杂度、团队规模、数据规模不断变化的过程中，被现实反复捶打之后，才慢慢浮现出来的。

给正在做架构决策的同行几个建议：第一，别为了“规范”而规范，每一层都是为了解决具体问题才存在的，没有真实的问题驱动，抽象就是过度设计；第二，分层边界要落地到代码评审的硬性规则里，不然很快就是摆设；第三，多数据库、多实现、缓存这一类复杂问题，统一收纳在数据访问层内部解决，上层只认接口，这是让系统保持整洁的基本功。

这套三层架构走到今天，已经经历过一次主库切换、一次统计库引入、三轮接口重构、两轮领域建模局部试点。每次改动，架构都比之前更清晰一点。架构这件事，急不来，也懒不得。