分层架构正在瓦解：自治领域能力崛起

Photo by fabio on Unsplash

到2026年，用AI代码助手（比如阿里的通义灵码、百度的Comate）写代码的开发者，速度已经快到离谱。

但速度快，问题也暴露得彻底。一个业务领域能力——比如“下单”、“推荐”、“风控”——在传统分层架构里，代码散落在controller、service、dao各个层里。想搞清楚整个逻辑，得沿着调用链一路跑下来，拼凑出全貌。

问题不在代码量，而在归属权。这些能力在系统里没有自己的“家”。它们被分到不同技术层里，而这些层只为了组织实现细节，不是为领域本身服务的。

解决方案：自治领域能力

系统应该按自治领域能力来组织。一个领域能力就是一个独立的归属边界，它的可执行形态叫请求处理单元（RPU）。

RPU把一次域请求的完整处理收在一处：加载事实、构建上下文、做决策、输出结果。不再把一个能力切碎丢到不同的技术层里。

这就像美团的外卖配送系统：一个“配送调度”能力，它自己搞定订单数据、骑手位置、路况预测、派单决策，而不是让这些逻辑散落在不同的微服务或中间件里。RPU就是那个把所有东西装在一起的黑盒子，只暴露请求和响应。

对AI编码的意义

当AI代理要修改或生成代码时，如果每一个领域能力都整齐地封装在RPU里，AI只需要理解这个RPU的内部逻辑，而不需要遍历整个技术栈。这会极大降低认知负载，也减少改代码时不小心破坏其他能力的风险。

微信视频号的内容推荐，如果是一个自包含的RPU，AI可以快速定位到策略调整点，而不必担心影响到用户资料模块或者数据统计通道。

分层架构为什么撑不住了

传统分层（展示层、业务层、数据层）本来是为了解耦技术关注点。但它把领域行为切碎了。一个简单的“用户登录”能力，验证码在controller，密码校验在service，用户记录在DAO——这三个东西明明说的是同一件事。

自治领域能力不意味着放弃技术分层。RPU内部可以有自己的分层，但对外，它表现为一个不变的边界。这个边界由领域归属定义，而不是技术堆叠。

如何落地

从识别最核心的领域能力开始。比如淘宝的“商品搜索”，把它收成一个RPU：输入搜索词，返回结果列表。内部可以自己决定要不要缓存、要不要用ES、要不要做竞价排名。外部系统只管调用它。

这种方式也天然适合事件驱动架构和CQRS。RPU可以同时是命令处理器和查询处理器，只要保持自治。

未来，随着AI自主生成和维护代码的频率增加，自治领域能力会成为软件系统的主边界。不是分层，不是微服务，而是每个能力自己说了算。