复杂过程中的单一责任原则

Question

当我必须保证的过程相当复杂时，我总是有一个关于如何保证单一责任原则的问题。

我使用 3 层架构后端：控制器（我的 API 端点）|服务（单一职责功能）|数据（访问数据库）

假设我有一个进程ProcessA，它由4 个任务TasksA1、TasksA2、TasksA3、TasksA4 组成。

如果我的控制器层上暴露了一个端点，例如：POSTMethodProcessA

应该如何编写我的代码以尊重我的服务层上的单一责任原则？

我看到的选项：

选项1（控制器必须知道流程）：

class MyController {
  exports.processA = functions.https.onRequest(req, res) => {
    myservice.doTaskA1(); // single responsability on task1
    myservice.doTaskA2(); // single responsability on task1
    myservice.doTaskA3(); // single responsability on task1
    myservice.doTaskA4(); // single responsability on task1
  });
}

选项 2（服务了解流程并解除 Single 责任）

class MyController {
  exports.processA = functions.https.onRequest(req, res) => {
    myservice.doProcessA();
  });
}

//inside the service (the doProcessA method must be in charge of multiples tasks and loose the single responsability principle :
class MyService {
  function doProcessA() {
    this.doTasksA1();
    this.doTasksA2();
    this.doTasksA3();
    this.doTasksA4();
  }
}

如果任务本身是由多个作业组成的，这个问题对我来说更加复杂：FirstJobA1、SecondJobA1、ThirdJobA1 ...

应该如何在代码结构上处理这些复杂性层以尊重单一责任原则，这一直困扰着我。任何见解都会有很大帮助！

Answer 1

一个常见的误解是Single Responibility Principle 意味着一个类 （或服务或系统等）应该只做一件事。相反，SRP 意味着 主题必须有一个改变的唯一理由。

因此，每个任务都有单独的“服务”实现是很好的， 然后是一个协调整个过程的“聚合”服务：

service TaskA;
service TaskB;
service TaskN;

service Process{
    TaskA::run();
    TaskB::run();
    ...
    TaskN::run();
}

任务的更改不应影响不相关的任务。此外，在 进程不应影响子任务。这与 Common Closure 有关 原则 (CCP) 规定：

组件中的类应该针对相同类型的更改关闭在一起。影响组件的更改会影响该组件中的所有类，而不会影响其他组件。

或更非正式地：

将那些因相同原因同时发生变化的类聚集到组件中

这意味着如果TaskA的变化必然会导致TaskB的变化， 那么也许这两个应该是一个任务，而不是两个。

将它递归地应用于您的子任务：FirstJobA1...FirstJobA-N