1.3.2　松耦合

松耦合是系统的一个基本属性，根据该属性，系统的各个组成部分之间对彼此的了解要尽可能的少。它的目标是每个部分都能独立演进，这样当某一部分发生变化的时候，其他组成部分无须相应地变化。

几十年来，耦合及其伴生的内聚理念在软件工程中发挥了重要的作用。将系统分解成模块（模块化），这些模块对其他部分的依赖达到最小（松耦合），并且将联系紧密的代码封装在一起（高内聚），这是一种良好的设计实践。根据不同的架构风格，模块可以建模成一个单体组件或一个独立的服务（例如，微服务）。不管采用哪种方式，我们都应该以实现松耦合和高内聚的恰当模块化为目标。

Parnas指出了模块化的三个收益[8]。

[8]　D. L. Parnas, “On the criteria to be used in decomposing systems into modules”, Communication of the ACM, 1972: 1053–1058。

■ 管理方面：鉴于每个模块都是松耦合的，所以负责团队应该不需要与其他团队进行过多的沟通和协调。

■ 产品的灵活性：每个模块都可以独立于其他模块演进，所以这会形成一个非常灵活的系统。

■ 可理解性：人们应该能够理解和运作单个模块，而不必学习整个系统。

上面所述的收益通常也是微服务所带来的部分收益。事实上，要实现它们，并不一定要采用微服务。在最近几年中，很多组织决定从单体迁移至微服务。但是，其中有些组织因为缺乏恰当的模块化而宣告失败。单体由紧耦合、非内聚的组件组成，当进行迁移的时候，会产生一个紧耦合、非内聚的微服务系统，它有时候也被称为分布式单体。我认为这并不是一个好的名字，因为它暗示着，按照定义单体是由紧耦合、非内聚的组件组成。而事实并非如此。架构风格并不重要：糟糕的设计就是糟糕的设计，与架构风格无关。事实上，我喜欢Simon Brown提出的“模块化单体”这个术语，它可以提高人们的认知，那就是单体也可以提升松耦合和高内聚，而且单体和微服务最终都有可能成为“大泥球”。

在本书中，我将会展示一些如何在应用中强制实现松耦合的技术。尤其是，我将会采用面向服务的架构，专注于构建具有明确接口的服务，以便于服务间的相互通信，并将与其他服务的依赖降至最低从而实现高内聚。