单一职责原则：软件世界中最重要的规则 - DZone

单一职责原则SRP，这是整个软件世界中最重要的单一规则。它几乎可以在我们系统的所有级别上看到：从单个类到整个应用程序（无论使用的规模和架构如何）设计。

什么是单一职责原则

可能你们中的大多数人将 SRP 解释与一个声明联系起来——类应该只做一件事。这是对这条规则最常见的解释，但不幸的是，它并不是 100% 符合作者所写的。

这条规则是由 Robert C. Martin 定义的，最初是这样说的：“一个类应该只有一个改变的理由”。在他后来的一本书中，作者将其提炼为：“一个模块应该对一个且只有一个角色负责”。术语模块最初被定义为单个源文件，而参与者被定义为对特定更改感兴趣的一个人或一组人。正如您所看到的，这两个定义与单一职责原则的最常见解释大不相同，但实际上，这使其在某些地方更加明显。

此外，SRP 表示这种方式与模块的业务职责更相关，而不是模块内部的确切代码。它还旨在将我们的注意力转移到思考为什么一段特定的代码在做某事，而不是实际上只考虑一段代码需要做什么。这种视角的改变可以带来很大的帮助，并帮助我们以不同的方式看待我们的系统。也许我们甚至在应用程序的某些部分看到了新的含义。

我们将首先描述单个类何时符合 SRP。

当类符合单一职责原则时

当我们按照 Robert C. Martin 的理解将单个类（确切地说是单个公共类；我假设我们在单个 . 文件中有一个这样的类）作为模块时。

最重要的是，理论上，该类可以做不止一件事——例如，在某些业务逻辑旁边执行数据库操作。不幸的是，所有这些都有一个问题：只要所有这些操作都是围绕单个业务功能构建的，它就可以以这种方式工作。因此，简单来说，我们可以执行各种操作，只要它们只涉及我们域的一个部分。

例如，在转账的情况下，它应该只负责传入转账，而不是同时负责传出、传入和国际转账。此外，在这个特定的例子中，我们的类设计必须足够灵活，不需要在数据库架构更新后进行更改。

在此之后，希望在类级别上下文中对 SRP 进行清楚的解释，我们将继续描述我们可以注意到的 SRP 和 DDD 之间的关系。

单一职责原则和领域驱动设计

领域驱动设计就是了解现实生活中的领域，然后在我们开发的软件中表达它们。它包含许多构建块，从有界上下文等高级概念到实体或值类等更低级的东西。在我看来，整个 DDD 与 SRP 有很大关系，有意无意，几乎所有前面提到的构建块都符合。

例如——有界上下文。它应该强烈关注域的一个特定部分，因此从业务角度来看，它有一组特定的利益相关者负责其开发——它只有一个参与者。有界上下文表示不相关的概念的情况是不可能的，并且可能表明您的域建模中存在大问题。因此，如果我们决定将限界上下文视为一个模块，我们可以很快注意到，通过他的定义，它完全符合 SRP。当然，限界上下文之间可能存在依赖关系，但不应该出现一个限界上下文的更改需要其他任何一个限界上下文的更改的情况。出现此类问题可能表明您的域建模过程中出现了一些错误。

此外，我相信所有较小的 DDD 构建块（如实体和值对象）都符合单一职责原则的定义。它们旨在为整个领域中的一个且仅一个概念建模。即使我们在设计限界上下文时失败并将来自域内部的不相关概念混合在一起，实体内部仍然应该仅对域的一个元素进行建模。

在聚合的情况下，事情可能会更复杂。根据定义，哪个应该将较小的构建块组合在一起，以便潜力和聚合可以对多个参与者负责。另一方面，聚合不应跨越多个有界上下文，因此较小的构建块应该在域的同一部分内紧密耦合。

如您所见，在领域驱动设计的情况下，我们可以注意到很多 SRP 接触。在有界上下文形式的战略 DDD 和以实体或聚合等块形式的战术 DDD 中。

系统级单一职责原则

正如我之前提到的，我们可能不仅在小范围内看到 SRP 的影响。它也可以在几乎所有现代架构方法中注意到。事实上，无论您选择使用单体应用程序还是面向服务架构的某种变体，或者是事件驱动的方法，如果您深入研究，您会注意到 SRP 对这些风格中的每一种的影响——如果是单体应用，它将会是一些损坏的 SRP。

我们将从简单的旧单体及其与 SRP 的关系开始我们的旅程。在某种程度上，它将反映在其他一些架构风格中。

• 单一职责原则和单体您可能知道，整体设计有 3 种主要方法——好的、坏的和丑陋的：模块化单体，几乎可以转变为微服务。这里我们应用程序中的每个模块负责整个系统提供的部分业务功能。如果您使用 DDD，那么这些模块中的每一个都可能基于单独的有界上下文。分布式单体，尝试实现微服务不幸失败（大量同步通信和分布式系统的所有问题）；这种情况在某种程度上是另外两种情况的结合。传统的单体应用，没有明确拆分成模块，而是部署在一台机器上，没有分发，模块之间有很多直接依赖。如果您仔细阅读以上部分，您可能会注意到每种方法和 SRP 之间的关系是不同的。另一方面，您可能还会注意到模块化单体至少受 SRP 的影响。
• 面向服务的架构和单一职责原则在这种情况下，SRP 的影响是显而易见的。基于它们中的任何一个的系统中的每个此类服务都应该负责整个域的特定部分，并且不应该出现来自不相关域的利益相关者负责引入其他域服务的更改的情况。基本上，这两种架构都在一定程度上基于 SRP。确切地说，两者都基于在服务之间拆分业务责任，而不是将它们混合在一个服务中。
• 事件驱动架构和单一职责原则
• 一开始，事件驱动系统中的模块是松散耦合的，几乎没有明确的直接依赖关系。事实上，在对系统中的特定服务进行更改时，除了服务交换的事件中的更新之外，其他服务应该不需要更改。基本上，这就是 SRP 在这种方法中的作用。

一般而言，如果架构风格基于自治、以功能为中心且松散耦合的模块/服务/部分，那么您可以确定它在创建过程中的某个地方受到了 SRP 的影响。此外，您会注意到，大多数被认为是当今不错选择的架构方法在设计时都考虑了 SRP。如果这种影响是偶然的或有意识的，那是一个完全不同的话题，我认为它更多地是关于在组件之间拆分业务责任。

此外，构建模块之间高耦合或在单个模块中混合业务功能的应用程序似乎已经成为过去，并且是制作非常美味的意大利面条的直接而清晰的方法。