关注点分离：从函数边界到服务边界的判断力

关注点分离可能是软件工程中被引用最多、理解却最模糊的原则。几乎每个开发者都能说出“高内聚、低耦合”，但真正动手时，问题立刻变得具体：这个函数要不要拆？这个模块该不该独立？这个服务边界划在哪里？拆得太细，调用链变长，调试困难；拆得太粗，改一处牵动全身。关注点分离不是“越分越好”，而是一种关于边界的判断力。它要求设计者理解变化的来源、变化的频率，以及变化的传播路径。下面不从定义出发，而从几个真实的判断场景切入。

从一次函数拆分说起

假设有一个处理订单的函数，代码大约八十行：校验参数、计算折扣、扣减库存、生成支付单、发送通知、写日志。团队里有人提议拆成六个小函数，理由是“每个函数只做一件事”。这听起来符合关注点分离，但拆完之后出现了新问题：参数在六个函数之间传来传去，中间状态需要一个上下文对象，错误处理散落在各处，阅读代码要跳转六次才能理解完整流程。

问题不在于“拆”本身，而在于拆分的依据。关注点分离的核心不是“每个函数短”，而是“每个模块封装一个会独立变化的决策”。如果折扣规则经常变，那折扣计算应该独立；如果通知渠道会从邮件扩展到短信、推送，那通知应该独立；如果库存扣减涉及并发和事务，那它也应该独立。但如果这些步骤总是同时变化、共享同一套上下文，强行拆开只会增加认知负担。

判断标准可以归结为一句话：拆分后的两部分，是否会因为不同的原因、在不同的时间、被不同的人修改。如果答案是否定的，那它们可能属于同一个关注点。

分层的代价常被低估

分层架构是关注点分离最典型的应用。Controller 处理请求，Service 编排业务，Repository 访问数据，Model 承载结构。这套模式被广泛采用，因为它确实解决了很多问题：替换数据库不影响业务逻辑，调整接口不影响数据访问，测试可以针对单层进行。

但分层也有代价，而且常常被低估。最常见的问题是“贫血分层”：Controller 只做参数转发，Service 只做方法透传，Repository 只做单表查询，每层都没有真正的决策，只是把调用链拉长。一个简单的查询要穿过四层，改一个字段要动四个文件。这时候的分层不是分离关注点，而是分离了代码，却没有分离责任。

另一个代价是“跨层泄漏”。业务规则本应在 Service 层，却因为性能原因写进了 SQL；权限判断本应在 Controller 层，却散落在各个 Service 方法里；事务边界本应由业务决定，却被 Repository 的注解固定。一旦边界被穿透，分层就变成了形式，维护者不知道该信任哪一层。

分层的健康信号不是层数，而是每一层是否有明确的、不可替代的职责。如果某一层可以被删除而不影响任何决策，那它可能只是仪式。

前端组件：什么时候该拆成两个

前端框架把组件变成了基本的组织单位，于是“组件拆分”成了关注点分离最日常的练习。一个页面组件可能同时处理数据请求、状态管理、表单校验、布局渲染和交互反馈。拆成多个组件是自然的，但拆法差异很大。

常见的错误拆法是按视觉区块拆：头部一个组件、侧边栏一个组件、内容区一个组件、底部一个组件。这种拆法看起来整洁，但每个组件仍然混杂了数据、状态和交互，只是把一个大文件变成了四个中等文件。真正有价值的拆法是按职责拆：容器组件负责数据获取和状态编排，展示组件负责渲染和局部交互，逻辑钩子负责可复用的状态逻辑。

前端还有一个特殊问题：状态放在哪里。全局状态、页面状态、组件状态、URL 状态、服务端缓存状态，各有归属。把所有状态都放进全局 store，是另一种关注点不分离。好的做法是让状态尽量靠近使用它的组件，只有真正跨组件、跨路由、跨会话的状态才提升。这不是技术选择，而是对状态生命周期的判断。

服务拆分：边界不是越小越好

微服务的流行让关注点分离从代码层面上升到了系统层面。理论上，每个服务负责一个业务能力，独立部署、独立扩展、独立演进。实践中，服务拆分带来的分布式复杂度常常超过它解决的问题：网络调用替代了函数调用，分布式事务替代了本地事务，服务发现、熔断、重试、链路追踪成为必需。如果拆分依据不充分，团队会陷入“分布式单体”的困境：服务之间高度耦合，每次发布要协调多个服务，故障排查要跨多个日志系统。

服务边界应该围绕业务能力，而不是技术分层。一个常见的错误是按技术拆：用户服务、订单服务、支付服务、通知服务。这看起来清晰，但如果“下单”这个业务流程需要同时修改订单、支付、库存、通知四个服务，那每次需求变更都要跨团队协调。更好的边界是围绕“谁在什么情况下需要独立变化”来划。如果库存规则和订单规则总是同时变化，它们可能属于同一个服务；如果支付渠道经常独立扩展，它适合独立。

判断服务边界时，可以问几个问题：这个服务是否拥有自己的数据？它的变更是否独立于其他服务？它能否在不影响其他服务的情况下部署？它的失败是否可以被隔离？如果答案是否定的，那它可能只是模块，而不是服务。

分离与协作的平衡

关注点分离有一个容易被忽略的孪生原则：关注点需要协作。分离的目的是让每个部分可以独立理解和修改，而不是让它们互不通信。过度分离的系统会出现“集成地狱”：每个模块单独测试都通过，组合起来却无法工作，因为接口假设不一致，错误语义不统一，数据格式对不上。

好的分离会同时定义清晰的协作契约。接口不只是方法签名，还包括错误约定、幂等性、超时行为、数据所有权和版本策略。模块之间的依赖应该是显式的、可追踪的，而不是通过全局变量、隐式约定或共享数据库表来“暗通款曲”。

一个实用的判断方法是：如果把两个模块之间的调用关系画成图，这个图是否容易理解？是否存在循环依赖？是否存在某个模块被所有模块依赖，却没有任何模块被它依赖？是否存在两个模块总是成对修改？这些信号比“模块数量”更能说明分离是否健康。

什么时候不该分离

关注点分离的反面不是“不分离”，而是“在错误的时机分离”。以下几种情况，保持在一起可能更合理。

当变化方向还不明确时，不要提前分离。过早抽象会锁定错误的边界，后续修改成本更高。当两个部分共享大量上下文、必须同时理解时，分开会增加认知成本。当性能要求极高、跨边界调用有显著开销时，分离可能得不偿失。当团队规模很小、沟通成本很低时，模块边界可以更粗。当业务规则频繁变化、边界本身不稳定时，先把逻辑放在一起，等稳定后再拆。

这些判断没有统一公式，但有共同的思考方式：分离是一种投资，它用短期的结构成本换取长期的修改自由度。如果长期自由度的收益小于短期成本，就不该分离。

在变化中寻找边界

关注点分离最终不是关于代码，而是关于变化。它假设系统会变，而不同的变化有不同的来源、频率和影响范围。好的边界让每种变化可以在自己的区域内完成，不需要理解整个系统；坏的边界让每次变化都牵一发而动全身，或者让简单的事情穿过层层抽象。

判断边界时，可以回到几个朴素的问题：谁最常修改这里？修改时还需要同时改什么？如果把这部分单独拿出来，它能否被独立理解、独立测试、独立替换？如果答案指向同一个方向，那就是合理的边界。如果答案模糊，也许还不该急着分。软件设计没有一劳永逸的分离方案，只有随着认知加深不断调整的边界判断。这种判断力，比任何架构图都更重要。