1. 一个具体问题
修改页面颜色需要碰到订单计算，增加一种导出格式又必须复制权限判断。文件已经按“页面”“服务”“工具”分了目录，问题却没有减轻。目录分开只是物理整理，真正需要分离的是能够独立理解和独立变化的责任。
2. 一句话解释
关注点分离是把不同问题与变化原因明确区分，使人能在有限范围内理解、实现和验证一个方面。
3. 出处与原意
Edsger Dijkstra 在 1974 年《On the Role of Scientific Thought》中讨论分离关注点的思维方式。它不仅是某种软件分层规范，也是一种暂时集中注意力、分别分析问题的方法。实际架构需要再把这些方面通过契约组合起来。
4. 原理与机制
人能同时处理的关系有限，混合展示、业务规则、存储和访问控制会增加推理负担。合适的分离让每一部分拥有明确输入、输出与变化来源，修改时不必理解整个系统。但关注点不总对应独立文件：日志和权限可能横跨多个模块，业务规则也可能需要多个组件协作。分离必须配合连接机制，否则只是把同一个难题搬到接口之间。评价标准包括变化是否局部、测试是否聚焦，以及整体行为是否仍容易追踪。
分离以后，契约本身会成为需要维护的关注点。例如业务层返回“失败”太模糊，界面就不得不猜测是输入问题还是暂时不可用；若错误类型过度细碎，又会让界面依赖内部实现。应按调用者需要采取的不同动作来定义结果，让边界传递必要语义。端到端测试则检查分离后的各部分是否仍共同实现同一项用户承诺。
5. 一个完整案例
假设案例：一个活动报名页面在按钮事件里计算名额、写数据库并拼接邮件。团队先提取“提交报名”这一用例，统一检查资格和剩余名额；页面只收集输入并显示结果，通知模块在报名成功后发送消息。邮件失败不会把已确认的报名变成未报名，而是进入可重试队列。测试分别验证名额约束、输入展示和通知重试，并保留一条完整流程测试确认连接正确。分离带来的收益是修改邮件样式不再触碰名额规则，同时没有丢失端到端正确性。
6. 适用条件与反例
适合处理多种变化纠缠、难以测试和职责不清的问题。过度分层会增加跳转和参数传递，甚至让简单流程难以追踪。规模小且生命周期短的程序，可以用清楚的函数和命名实现分离，不必立即拆服务或引入复杂框架。
7. 今天可以尝试的行动
拿一段经常修改的逻辑，用不同颜色标出展示、规则、外部通信和持久化。选择最容易独立验证的一部分提取，写清失败时由谁负责。改动后沿一次真实操作走完整流程，确保分离没有制造新的责任空白。