三层架构后端复杂流程下Service层如何遵守单一职责原则？

很多人对单一职责原则存在误解，它的核心定义是「一个模块/类/方法只有一个引起变更的原因」，绝非要求一个类只能实现一个细粒度操作、不能串联多个步骤。你提到的两个方案的问题本质是职责边界划分错误，而非流程封装本身违反原则：

• 方案1的问题：将业务流程逻辑耦合在仅负责HTTP请求处理的Controller层，不仅会导致Controller臃肿，还会让业务流程无法被其他内部服务/接口复用，同时Controller会同时存在「请求规则变更」和「业务流程变更」两个修改原因，反而违反单一职责。
• 方案2的问题：将原子任务实现和流程编排放在同一个Service类中，导致类同时承担「原子任务逻辑修改」和「流程规则修改」两个变更原因，才是真正的职责过载。

推荐的分层拆分结构 #

按照职责拆分为4个独立层级，每层严格遵守单一职责：

1. 原子作业层 #

将最小粒度的不可拆分的业务逻辑封装为独立的Service类，每个类仅负责自己的逻辑实现，只有对应逻辑修改时才会变更该类。
示例代码：

// 每个子作业仅负责自己的核心逻辑
class FirstJobA1Service {
  run() {
    // 具体业务实现
  }
}
class SecondJobA1Service {
  run() {}
}

2. 任务层 #

每个任务类仅负责编排自己所属的所有子作业，只有该任务的内部子作业执行顺序、增减规则修改时才会变更该类。
示例代码：

class TaskA1Service {
  constructor() {
    this.firstJob = new FirstJobA1Service();
    this.secondJob = new SecondJobA1Service();
  }
  run() {
    this.firstJob.run();
    this.secondJob.run();
  }
}
// 其他TaskA2、TaskA3、TaskA4类同理实现
class TaskA2Service { run() {} }
class TaskA3Service { run() {} }
class TaskA4Service { run() {} }

3. 流程编排层 #

单独设置流程编排Service，唯一职责是按照业务规则串联ProcessA的所有任务，只有ProcessA的整体流程修改时才会变更该类。
示例代码：

class ProcessAOrchestrationService {
  constructor() {
    this.taskA1 = new TaskA1Service();
    this.taskA2 = new TaskA2Service();
    this.taskA3 = new TaskA3Service();
    this.taskA4 = new TaskA4Service();
  }
  run(params) {
    const result1 = this.taskA1.run(params);
    const result2 = this.taskA2.run(result1);
    this.taskA3.run(result2);
    return this.taskA4.run();
  }
}

4. Controller层 #

仅负责HTTP请求相关的逻辑处理：参数校验、权限校验、调用编排服务、封装响应结果，只有请求相关的规则修改时才会变更该类。
示例代码：

class MyController {
  constructor() {
    this.processAService = new ProcessAOrchestrationService();
  }
  exports.processA = functions.https.onRequest(req, res) => {
    // 仅做请求参数校验
    const checkResult = validateRequestParams(req);
    if (!checkResult.valid) {
      return res.status(400).send({ error: checkResult.msg });
    }
    // 调用编排服务执行业务流程
    const processResult = this.processAService.run(checkResult.data);
    // 封装响应返回
    return res.status(200).send({ data: processResult });
  });
}

方案优势 #

• 全链路符合单一职责：每层、每个类只有一个变更原因，互不干扰
• 复用性强：任意原子作业、任务、流程都可以被其他业务场景直接调用，不需要重复实现
• 可测性高：每个类都可以独立编写单元测试，不需要强依赖其他模块的逻辑

内容的提问来源于stack exchange，提问作者Aion