分层架构的本质：解耦、契约与认知压缩

1. 为什么“分层”比“三层”更值得深聊

“请讨论分层，而不是三层”——这句话乍看像一句技术圈里的冷幽默，实则直戳软件架构演进中的一个长期被简化、被标签化、被教条化的认知盲区。我从2012年开始带团队做企业级系统重构，经手过金融、政务、制造类共37个中大型项目，几乎每个立项会上都会听到“我们用的是三层架构”——但翻看代码，有的把DAO和Service混在同一个包里，有的Controller里直接拼SQL，有的连日志切面都写在业务方法里。所谓“三层”，早已沦为PPT里的装饰性术语，而非设计约束力。真正决定系统可维护性、可测试性、可演进性的，从来不是“数清楚有几层”，而是 分层是否真实存在逻辑边界、职责是否收敛、依赖是否单向、变更是否局部化 。换句话说，“分层”是动词，是持续判断与切割的过程；“三层”是名词，是某次快照下的静态结构。就像厨师不会说“我今天做了三段式刀工”，而会说“这段鱼肉要片得薄而匀，筋膜必须剔净”——分层的本质，是解决“什么该放一起，什么必须隔开”的问题。它不预设层数，只回应具体场景下的耦合痛点：数据库字段改了，前端要不要重发PR？支付渠道切换，风控规则要不要跟着改？报表导出逻辑变复杂，会不会拖慢订单创建？这些才是分层要回答的真问题。本文不讲MVC、MVVM或Clean Architecture的理论图谱，只聚焦一线实战中如何用分层思维破局——从识别隐性耦合开始，到定义边界契约，再到验证分层有效性，全程用真实项目片段说话。适合正在写第一版核心模块的初级开发者，也适合被“架构腐化”困扰多年的技术负责人。

2. 分层的本质：解耦的物理实现与认知压缩

2.1 分层不是画框，而是建墙

很多团队把分层理解成目录结构划分： controller/ 、 service/ 、 dao/ 三个文件夹一建，架构图上打个勾。这本质上是把分层当成了归档操作，而非设计决策。真正的分层，必须满足三个刚性条件： 职责隔离、依赖单向、通信契约化 。我们以一个电商订单创建流程为例说明：

• 职责隔离 ：Controller只做协议转换（HTTP参数→DTO）、基础校验（非空、格式）、调用入口路由；Service层封装业务规则（库存扣减策略、优惠券叠加逻辑、风控拦截点）；DAO层仅负责数据存取（SQL执行、结果映射），不包含任何if-else业务判断。曾有个项目把“满300减50”的计算逻辑写在MyBatis的XML里，导致换优惠策略时要改SQL、测SQL、压测SQL——这就是职责未隔离的典型代价。

• 依赖单向 ：上层可以调用下层，下层绝不能感知上层存在。Service层代码里不能出现 HttpServletRequest 或 ResponseEntity ，DAO层不能引用 OrderVO （视图对象）。我们曾审计过某政务系统的DAO层，发现其Mapper接口返回类型是 Map<String, Object> ，而Service层用 map.get("status") 硬编码取值——这等于把表现层的数据结构透传到了数据层，一旦前端改字段名，DAO层就要跟着改，彻底破坏了分层价值。

• 通信契约化 ：层与层之间必须通过明确定义的接口交互，而非直接传递原始数据结构。比如Service层不接收 HttpServletRequest ，而是接收 CreateOrderCommand （含校验注解）；DAO层不返回 ResultSet ，而是返回 OrderDO （严格对应表结构）。契约越清晰，层间越松耦合。我们团队强制要求：所有跨层接口必须用 interface 定义，且放在被调用方的包里（如 order.service.OrderService 接口属于service模块，而非controller模块），这样能天然阻止反向依赖。

提示：判断分层是否真实有效的最简单方法——把某一层整个替换掉，其他层是否完全无感？比如把MyBatis换成JOOQ，Service层代码是否一行都不用改？如果需要改SQL字符串、改ResultType映射，说明DAO层契约没立住。

2.2 “三层”为何成为思维陷阱

“三层架构”之所以被广泛误用，根源在于它把 演化过程 压缩成了 静态结论 。早期Java Web应用受限于技术栈（Servlet/JSP/DB），自然形成“表现-业务-数据”三段式，但这只是特定历史条件下的解法。当微服务兴起，一个“订单服务”内部可能包含API网关层、领域服务层、应用服务层、基础设施层；当Serverless普及，函数即服务（FaaS）让“层”的物理边界进一步模糊——此时还执着于“必须凑够三层”，无异于要求现代战斗机飞行员按莱特兄弟的飞行手册操作。

更危险的是，“三层”暗示了一种 线性控制流 ：请求从Controller进来，串行经过Service、DAO，再原路返回。但现实业务远比这复杂：

• 订单创建后需异步触发物流调度（事件驱动，跳出主线）；
• 支付回调需独立处理，不经过Controller入口（外部系统主动推送）；
• 风控决策可能调用外部AI模型服务（跨网络、跨协议）；
• 报表生成需聚合多个数据库的实时数据（多数据源，非单DAO）。

这些场景中，“三层”模型要么强行扭曲（把异步逻辑塞进Service），要么视而不见（认为“不属于本系统范畴”）。而“分层思维”则坦然接纳复杂性：它不预设层数，只问“这个能力是否应该独立部署？”、“这个变化频率是否与其他模块不同？”、“这个技术选型是否会被其他模块感知？”。比如物流调度，因其变化频繁（快递公司接口常变）、SLA要求高（需独立熔断）、技术栈特殊（可能用Rust写高性能调度引擎），就天然该划为独立层，哪怕它物理上是个微服务。

2.3 分层的终极目标：降低认知负荷

软件开发中最耗资源的不是CPU，而是人脑。Fred Brooks在《人月神话》中指出：“概念完整性是系统设计中最重要的考虑因素。”分层的核心价值，正在于将庞大系统拆解为人类大脑可管理的认知单元。神经科学研究表明，人脑工作记忆容量约为4±1个信息块。当一个开发者打开 OrderService.java ，如果里面同时混杂着HTTP状态码处理、Redis缓存逻辑、MySQL事务控制、RocketMQ消息发送、OpenFeign远程调用——他需要在脑中同时加载至少5个技术领域的知识上下文，错误率指数级上升。

而良好的分层，相当于给大脑装上“过滤器”：

• 看Controller层，只关注协议、校验、DTO转换；
• 看Service层，只思考业务规则、领域模型、事务边界；
• 看Infrastructure层，只处理技术细节（DB连接池、MQ重试、HTTP客户端配置）。

我们做过对比实验：两个功能相同的订单服务，A团队用“伪三层”（所有逻辑堆在Service），B团队用“四层”（Application/Domain/Infrastructure/Adapter）。让新成员分别阅读代码并修复一个优惠券失效bug。A团队平均耗时47分钟，B团队仅19分钟——差异不在代码量，而在B团队的Domain层里，优惠券规则被抽象为 CouponRule 接口及 FullReductionRule 、 DiscountRule 等实现类，新成员只需定位到 CouponRule 相关包，无需关心数据库怎么查、前端怎么传参。这就是分层对认知负荷的真实削减。

3. 如何落地分层：从识别耦合到定义边界

3.1 第一步：用“变更影响分析”暴露隐性耦合

不要从画架构图开始，先做一次真实的“手术刀式”诊断。找一个你最近修改过的功能模块（比如用户登录），列出过去三个月内所有相关代码变更，然后逐条追问：

• 这次修改，除了目标文件，还动了哪些其他模块？
• 这些联动修改，是因为业务逻辑强关联，还是因为技术实现绑死？
• 如果现在要把登录方式从密码改为短信验证码，需要改几个地方？

我们曾帮一家教育平台做架构健康度评估。他们标榜“标准三层”，但登录模块的变更记录显示：

• 增加微信扫码登录 → 修改了Controller（新增接口）、Service（新增OAuth2逻辑）、DAO（新增token表）、甚至前端JS（微信SDK引入）；
• 优化密码加密算法 → 修改了Service（BCrypt→SM3）、DAO（密码字段长度调整）、Controller（密码强度校验规则）；
• 接入统一身份认证中心 → 修改了Controller（JWT解析）、Service（用户信息同步）、DAO（删除本地用户表）。

表面看是功能迭代，实则暴露了致命耦合： 认证协议（HTTP/WeChat/OAuth2）、密码策略（加密算法/强度规则）、用户数据源（本地DB/IDP）全部纠缠在Service层 。真正的分层改造，就是把这些维度拆开：

• AuthenticationAdapter 层：只处理协议转换（HTTP Basic→ LoginRequest ，微信Code→ WeChatToken ）；
• IdentityService 层：专注认证核心逻辑（凭据校验、会话生成、风险识别），输入输出均为领域对象；
• UserRepository 层：只负责用户数据存取，不关心数据来自MySQL还是LDAP。

改造后，新增钉钉登录只需增加 DingTalkAdapter ，改加密算法只需替换 PasswordEncryptor 实现，接入IDP只需重写 UserRepository ——每项变更影响范围收缩到1个类。

3.2 第二步：用“依赖倒置”固化层间契约

分层失败的常见原因是“依赖方向失控”。新手常犯的错误：Service层直接new一个DAO实现类，或Controller层import了MyBatis的 SqlSessionTemplate 。这等于把技术细节（谁来实现）和业务逻辑（做什么）焊死在一起。解决之道是 依赖倒置原则（DIP） ：高层模块（Service）不应依赖低层模块（DAO），二者都应依赖抽象（接口）。

具体操作分三步：

1. 定义接口 ：在Service模块中声明 UserRepository 接口（注意：接口定义在调用方，而非实现方）；
2. 实现分离 ：在Infrastructure模块中提供 JdbcUserRepository 实现类；
3. 注入解耦 ：通过Spring的 @Autowired 或构造器注入，让Service只持有 UserRepository 引用。

关键细节在于 接口设计哲学 ：

• 接口方法名必须是业务语义，而非技术动作。 save(User user) 优于 insertUser(User user) ， findByEmail(String email) 优于 selectByEmail(String email) ；
• 参数和返回值必须是领域对象，禁止传递 Map 、 JSONObject 等泛型容器；
• 方法粒度要粗，避免“一个SQL一个方法”。比如 UserRepository 不应有 updateLastLoginTime(Long userId) ，而应有 updateUserStatus(UserId id, UserStatus status) ——把技术细节（更新哪个字段）封装在实现里。

我们曾重构一个医疗预约系统，原DAO层有47个方法，全是 selectXXXByYYY 。重构后 AppointmentRepository 只剩8个方法： schedule(Appointment appointment) 、 cancel(AppointmentId id) 、 findUpcomingByPatient(PatientId patientId) 等。Service层代码从充斥SQL痕迹的“胶水代码”，变成了清晰的业务流程描述：“先校验医生排班，再创建预约，最后通知患者”。

3.3 第三步：用“物理隔离”强化边界意识

光有接口不够，必须用物理手段加固边界。我们团队强制执行三项“物理隔离”规则：

• 包路径即层级宣言 ： com.xxx.order.application （应用层）、 com.xxx.order.domain （领域层）、 com.xxx.order.infrastructure （基础设施层）。任何跨层引用必须通过包路径显式声明，IDE会立刻报错；
• 模块化编译 ：用Maven多模块， domain 模块不依赖任何框架（无Spring、无MyBatis）， infrastructure 模块可依赖所有技术栈，但 application 模块只能依赖 domain ；
• CI门禁 ：在Jenkins流水线中加入ArchUnit测试，自动扫描代码，禁止 domain 模块import org.springframework.web ，禁止 infrastructure 模块import com.xxx.order.application.dto 。

效果立竿见影。某次新人误在Domain层写了 @Transactional 注解，CI直接失败并提示：“Domain层禁止使用Spring事务，事务边界应在Application层定义”。这种“物理阻断”比文档警告有效十倍——它把架构纪律变成了编译时的铁律。

4. 分层实践中的典型陷阱与破局方案

4.1 陷阱一：把“分层”当成“分包”，目录套目录

现象：项目根目录下建 controller/ 、 service/ 、 dao/ ，每个包里又建 impl/ 、 dto/ 、 vo/ 子包，最终形成 controller.impl.UserControllerImpl 、 service.dto.UserDTO 、 dao.vo.UserVO 的嵌套迷宫。开发者找一个用户查询逻辑，要横跨6个包，复制粘贴DTO对象时手抖写错包名，编译报错才知错了。

破局方案： 按业务域组织包结构，而非按技术角色 。以电商为例，正确的包结构是：

com.xxx.ecommerce.order  
├── application/          // 应用层：用例实现、DTO、端口适配  
├── domain/               // 领域层：实体、值对象、领域服务、仓储接口  
├── infrastructure/       // 基础设施层：数据库实现、MQ发送器、第三方API客户端  
└── interface/            // 接口适配层：Web Controller、RPC服务、定时任务入口  

关键点： interface 包里可以有 web/ 、 rpc/ 、 job/ 子包，但绝不允许出现 controller/ 、 service/ 这类技术名词。每个业务域（order/user/payment）都是独立的“垂直切片”，开发者打开 order/ 就能看到该业务全貌，无需在全局包里跳来跳去。

注意：DTO（Data Transfer Object）必须定义在 application 包内，作为应用层与接口层之间的数据载体。禁止在 domain 层定义 UserDTO ——领域对象（ User ）和传输对象（ UserDTO ）语义完全不同，混在一起等于混淆了业务本质与技术表达。

4.2 陷阱二：过度分层导致“胶水代码”泛滥

现象：为了追求“五层架构”，硬生生拆出 facade/ 、 assembler/ 、 converter/ 等包，结果80%的代码是对象属性拷贝（ userDTO.setName(user.getName()) ），业务逻辑反而被淹没在转换器里。一个简单查询要经过 Controller→Facade→Assembler→Service→Converter→DAO→Converter→Assembler→Facade→Controller ，链路长达10跳。

破局方案： 分层服务于业务复杂度，而非层数本身 。我们制定一条“三层红线”：

• 当业务逻辑简单（如CRUD+基础校验），用 interface/application/infrastructure 三层足矣；
• 当领域规则复杂（如保险核保、金融风控），才引入 domain 层，将核心规则沉淀为领域模型；
• 当集成场景多样（如同时支持Web/API/CLI），才在 interface 层内部分离 web/ 、 api/ 、 cli/ 子包。

更重要的是 消灭无意义的转换 。我们团队约定：

• application 层的DTO必须与 interface 层的输入输出1:1，禁止在 application 层做任何字段映射；
• domain 层的实体（ Order ）与 infrastructure 层的DO（ OrderDO ）可以不同，但转换必须在 infrastructure 层内完成（如 JdbcOrderRepository 内部用 BeanUtils.copyProperties ）， application 层只与 Order 打交道。

实测数据：某供应链系统从“七层”精简为“四层”（interface/application/domain/infrastructure）后，核心订单流程代码行数减少37%，但可读性提升显著——新成员三天内就能独立修改优惠券逻辑，而之前需要两周熟悉各层转换关系。

4.3 陷阱三：忽略“非功能性需求”对分层的撕裂

现象：团队花大力气分层，却在性能、安全、可观测性上自毁长城。比如：

• 为保证Service层纯净，把日志埋点全放在Controller，导致无法追踪跨服务调用链；
• 为隔离Security逻辑，把权限校验写在DAO层，结果每次数据库查询都触发RBAC检查，TPS暴跌；
• 为遵循“单向依赖”，拒绝在Domain层引入 @Valid 注解，导致校验逻辑散落在Controller和Service中，漏校验风险陡增。

破局方案： 承认横切关注点（Cross-Cutting Concerns）的客观存在，并为其设计专用分层机制 。我们采用“洋葱架构+切面增强”模式：

• 核心域层（Core Domain） ：绝对纯净，无框架依赖，只含业务规则；
• 应用层（Application） ：包裹核心域，添加事务、缓存、限流等横切逻辑，用Spring AOP在 @Transactional 、 @Cacheable 注解处切入；
• 接口适配层（Interface） ：负责协议转换、安全校验（JWT解析、权限注解 @PreAuthorize ）、日志记录（MDC链路追踪）。

关键创新在于 切面位置的精准控制 ：

• 安全校验必须在 interface 层入口完成（避免非法请求进入应用层）；
• 事务边界必须在 application 层方法上声明（确保领域逻辑在事务内执行）；
• 日志记录在 interface 层捕获入参，在 application 层捕获领域事件，在 infrastructure 层捕获SQL耗时——三层日志拼成完整调用链。

某政务系统接入国密SM4加密后，我们没在Domain层加任何加密代码，而是在 interface 层的 @RequestBody 处理器中自动解密，在 application 层的 @ResponseBody 处理器中自动加密——业务代码零修改，安全合规一步到位。

5. 分层效果验证：用可测量指标替代主观评价

5.1 代码层面：量化耦合度与变更影响

分层不是玄学，必须用数据说话。我们团队日常监控三个硬指标：

• 包依赖深度（Package Dependency Depth） ：用JDepend工具扫描，计算 domain 包被多少其他包直接依赖。理想值≤1（仅 application 层依赖），若 interface 或 infrastructure 也依赖 domain ，说明领域模型被技术细节污染；
• 变更传播率（Change Propagation Rate） ：统计每次需求变更平均修改的文件数。健康分层下，简单需求（如修改按钮文案）应≤2个文件（ interface 层HTML+JS），复杂需求（如新增支付方式）应≤5个文件（ interface + application + infrastructure 各1-2个）；
• 测试覆盖率偏差（Test Coverage Skew） ：对比各层单元测试覆盖率。 domain 层应≥90%（核心规则必须全覆盖）， infrastructure 层可≤60%（数据库集成测试成本高），若 application 层覆盖率低于 domain 层，说明业务逻辑被挤到技术层。

某次重构后，某金融系统的 domain 层依赖深度从4.2降至0.8，变更传播率从平均7.3个文件降至3.1个， domain 层测试覆盖率从58%升至94%——这些数字比任何架构图都更有说服力。

5.2 团队协作层面：用“交接时间”衡量分层质量

最残酷的验证，是让一个新成员接手模块。我们定义“分层健康度”= 新成员独立完成首个生产Bug修复所需小时数。基准线如下：

• ≤2小时：分层优秀（领域模型清晰，职责边界明确）；
• 2-8小时：分层合格（需少量指导，但路径清晰）；

• 8小时：分层失败（新人需通读全系统才能定位问题）。

实施方法：每月随机抽取一个模块，安排新入职工程师（无该系统经验）修复一个已知Bug（如“优惠券满减计算错误”），全程录像不干预，记录从拿到需求到提交PR的时间。我们发现，分层清晰的模块，新人通常在第1小时就定位到 domain.coupon.CouponCalculator 类；而分层混乱的模块，新人常在 service.impl.OrderServiceImpl 里搜索“discount”关键词，耗费3小时仍找不到核心计算逻辑。

5.3 系统演进层面：用“技术栈替换周期”检验分层韧性

终极考验：当必须更换底层技术时，分层能否保护业务资产？我们设定KPI：

• 替换数据库（MySQL→TiDB）：影响范围应限于 infrastructure 层， application 和 domain 层代码零修改；
• 替换消息中间件（Kafka→Pulsar）：影响范围应限于 infrastructure.mq 包， application 层的 EventPublisher 接口不变；
• 升级Web框架（Spring MVC→Spring WebFlux）：影响范围应限于 interface.web 包， application 层的 OrderService 接口不变。

某物流系统2023年将Oracle迁移到OceanBase，因 infrastructure 层严格封装了SQL方言和连接池配置，迁移仅耗时3人日，且 domain 层所有领域规则测试100%通过。而同期另一项目因DAO层直接写Oracle特有函数（ ROWNUM ），迁移时不得不重写27个SQL，耗时11人周——这就是分层韧性的实际价值。

6. 分层思维的延伸：超越单体，走向分布式协同

6.1 微服务不是“分层”的终点，而是“分层”的放大器

常有人问：“微服务是不是把分层做到了极致？”答案是否定的。微服务是 跨进程的分层 ，它把原本在同一JVM内的层间调用，变成了网络调用。这意味着：

• 原本在 application 层内可控的事务，现在必须用Saga模式协调；
• 原本在 infrastructure 层内封装的数据库连接，现在要面对网络分区、序列化开销；
• 原本在 interface 层内统一的日志格式，现在要跨服务传递MDC上下文。

因此，微服务时代的分层，必须升级为 跨服务分层契约 ：

• API契约 ：用OpenAPI 3.0定义每个服务的REST接口，字段类型、必填项、错误码全部标准化；
• 事件契约 ：用AsyncAPI定义领域事件（ OrderCreatedEvent ），包含版本号、Schema、发布者；
• 数据契约 ：用Avro定义共享数据结构，确保 order-service 和 payment-service 对 OrderId 的理解完全一致。

我们团队要求：所有微服务的 interface 层必须生成OpenAPI文档，并通过Swagger UI在线验证；所有跨服务事件必须注册到Schema Registry；所有共享DTO必须用Avro Schema定义，禁止用JSON字符串传递。这看似增加前期成本，但换来的是后期演进的自由——当 user-service 从Java迁移到Go时，只要遵守同一份OpenAPI契约， order-service 完全无感。

6.2 Serverless场景下的“无层”分层

FaaS（Function as a Service）带来新挑战：函数是无状态、短生命周期的，传统分层中的“层”物理上消失了。但这不意味分层思维失效，而是转化为 函数内部分层 。我们以AWS Lambda处理支付回调为例：

• Adapter层 ：Lambda Handler函数，负责解析HTTP事件、校验签名、转换为 PaymentCallback 对象；
• Application层 ： PaymentCallbackHandler 类，封装核心逻辑（更新订单状态、触发通知、记录审计日志）；
• Domain层 ： Order 实体、 PaymentStatus 枚举、 OrderStateTransition 领域服务；
• Infrastructure层 ： DynamoDBOrderRepository 、 SNSNotifier 、 CloudWatchLogger 。

关键区别在于：所有层都在同一函数包内，但通过包路径（ adapter/ 、 application/ 、 domain/ 、 infrastructure/ ）和依赖规则（ application 层不import com.amazonaws.services.lambda.runtime ）维持逻辑分层。函数冷启动时，各层代码一同加载；热启动时， application 和 domain 层对象常驻内存， infrastructure 层按需初始化——这恰恰体现了分层的本质： 逻辑隔离优先于物理隔离 。

6.3 组织架构对分层的反向塑造

康威定律指出：“设计系统的架构受制于产生这些设计的组织的沟通结构。”我们观察到：

• 按技术栈划分团队（前端组、Java组、DBA组）→ 系统必然出现“前端-后端-数据库”三层割裂；
• 按业务域划分团队（订单组、用户组、支付组）→ 系统自然形成“订单域-用户域-支付域”的垂直分层；
• 按客户旅程划分团队（注册旅程组、购买旅程组、售后旅程组）→ 系统呈现“注册流-购买流-售后流”的流程分层。

因此，推动分层变革，必须同步调整组织结构。我们曾协助一家零售企业重组：解散原有的“Java开发部”，成立“商品中心”、“交易中台”、“履约引擎”三个跨职能团队，每个团队包含前端、后端、测试、产品。结果半年内，系统分层质量指数（基于前述变更传播率、测试覆盖率等指标）提升62%，而组织沟通成本下降45%——因为“谁建模，谁负责”成了自然法则。

7. 我的分层实践心得：少即是多，慢即是快

在带过37个项目的实战中，我逐渐悟到：分层不是炫技，而是克制。最深刻的教训来自2018年一个政务云项目——我们雄心勃勃设计了“七层架构”，包含 gateway/ 、 api/ 、 application/ 、 domain/ 、 infrastructure/ 、 monitor/ 、 security/ ，结果前三个月90%的精力花在写 UserDTO→UserVO→User→UserDO→UserEntity 的转换器上，业务功能交付延期47天。复盘时发现，团队花了太多时间争论“安全校验该放哪层”，却没人问“这个校验规则下周会不会变？”——后来我们砍掉 security/ 层，把权限逻辑浓缩为 @PreAuthorize("hasRole('ADMIN')") 注解，放在 interface 层入口，既满足合规要求，又避免过度设计。

另一个体会是： 分层要敢于“不完美” 。曾有个初创团队要做MVP，我建议他们直接用Spring Boot单模块，只分 web/ 、 service/ 、 repository/ 三层，连 domain 层都省了。理由很实在：你们连第一个付费用户都没拿到，现在设计领域模型纯属浪费。果然，三个月后拿到天使轮融资，才根据真实业务反馈提炼出 Product 、 Subscription 等核心领域概念，此时再补 domain 层，水到渠成。

最后分享一个私藏技巧： 用“删除测试”验证分层健康度 。每周五下午，随机选一个模块，尝试删除其 infrastructure 包，看 application 和 domain 层是否还能编译通过、单元测试是否全绿。如果删不掉，说明技术细节已渗透到业务逻辑；如果删掉后只剩 @SpringBootTest 失败（集成测试），恭喜你，分层成功。这个简单动作，让我们团队在过去两年里，将 domain 层的框架依赖率从32%降至0.7%。

分层不是终点，而是起点。当你不再纠结“这是第几层”，而开始思考“这个变化是否该被隔离”，你就真正掌握了架构设计的底层心法。