单一职责原则:软件世界中最重要的规则 - DZone( 二 )


  • 单一职责原则和单体您可能知道,整体设计有 3 种主要方法——好的、坏的和丑陋的:模块化单体,几乎可以转变为微服务 。这里我们应用程序中的每个模块负责整个系统提供的部分业务功能 。如果您使用 DDD,那么这些模块中的每一个都可能基于单独的有界上下文 。分布式单体,尝试实现微服务不幸失败(大量同步通信和分布式系统的所有问题);这种情况在某种程度上是另外两种情况的结合 。传统的单体应用,没有明确拆分成模块,而是部署在一台机器上,没有分发,模块之间有很多直接依赖 。如果您仔细阅读以上部分,您可能会注意到每种方法和 SRP 之间的关系是不同的 。另一方面,您可能还会注意到模块化单体至少受 SRP 的影响 。
  • 面向服务的架构和单一职责原则在这种情况下,SRP 的影响是显而易见的 。基于它们中的任何一个的系统中的每个此类服务都应该负责整个域的特定部分,并且不应该出现来自不相关域的利益相关者负责引入其他域服务的更改的情况 。基本上,这两种架构都在一定程度上基于 SRP 。确切地说,两者都基于在服务之间拆分业务责任,而不是将它们混合在一个服务中 。
  • 事件驱动架构和单一职责原则
  • 一开始,事件驱动系统中的模块是松散耦合的,几乎没有明确的直接依赖关系 。事实上,在对系统中的特定服务进行更改时,除了服务交换的事件中的更新之外,其他服务应该不需要更改 。基本上,这就是 SRP 在这种方法中的作用 。
一般而言,如果架构风格基于自治、以功能为中心且松散耦合的模块/服务/部分,那么您可以确定它在创建过程中的某个地方受到了 SRP 的影响 。此外,您会注意到,大多数被认为是当今不错选择的架构方法在设计时都考虑了 SRP 。如果这种影响是偶然的或有意识的,那是一个完全不同的话题,我认为它更多地是关于在组件之间拆分业务责任 。
此外,构建模块之间高耦合或在单个模块中混合业务功能的应用程序似乎已经成为过去,并且是制作非常美味的意大利面条的直接而清晰的方法 。

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


推荐阅读