下面是一个从抽象的图论角度给出的答案:

让我们通过只查看有状态对象之间的(有向)依赖关系图来简化这个问题。

一个极其简单的答案可以通过考虑依赖图的两种限制情况来说明:

第一个极限情况:聚类图。

簇图是高内聚低耦合(给定一组簇大小)依赖图的最完美实现。

簇之间的依赖性是最大的(完全连接)，而簇间的依赖性是最小的(零)。

这是一种极限情况下答案的抽象说明。

第二个极限情况是一个全连通图，其中所有东西都依赖于所有东西。

在我看来，现实情况介于两者之间，越接近聚类图越好。

从另一个角度来看:当观察有向依赖关系图时，理想情况下它应该是无循环的，如果不是，那么循环就会形成最小的集群/组件。

层次结构的上升/下降对应于软件中松耦合、紧密内聚的“一个实例”，但可以将这种松耦合/紧密内聚原则视为在无环有向图(或其生成树之一)的不同深度上的重复现象。

将系统分解为层次结构有助于克服指数级的复杂性(比如每个集群有10个元素)。在6层中，已经有100万个对象了:

10个星系团形成1个超星系团，10个超星系团形成1个超星系团……如果没有紧密内聚、松散耦合的概念，这样的层次结构就不可能实现。

所以这可能是故事的真正重要性，而不仅仅是两层中的高内聚低耦合。当考虑更高级别的抽象及其交互时，真正的重要性变得清晰起来。

当我读到微服务的时候。我发现了以下几点:

内聚性是对组件各部分之间的关系数量的度量。高内聚性意味着交付组件功能所需的所有部分都包含在组件中

耦合是系统中一个组件与其他组件之间关系数量的度量。低耦合意味着组件与其他组件之间没有太多关系

低耦合和高内聚是一个值得推荐的现象。

耦合意味着各个模块相互依赖的程度，以及其他模块在改变模块的某些/相当大的功能时是如何受到影响的。低耦合被强调，因为依赖关系必须保持在较低的水平，以便对其他模块进行非常少的/可以忽略不计的更改。

低耦合:—— 让它变得简单。 如果你改变了你的模块，它对其他模块有什么影响?

例子:- 如果您的服务API公开为JAR，对方法签名的任何更改都将破坏调用API(高/紧耦合)。

如果您的模块和其他模块通过异步消息通信。只要您获得消息，您的方法更改签名将是您模块的本地(低耦合)。

如果消息格式发生变化，则呼叫客户端将需要进行一些更改。

低耦合是在两个或多个模块的上下文中。如果一个模块中的变化导致其他模块中的许多变化，那么它们被称为高度耦合的。这就是基于接口的编程的用处。模块内的任何变化都不会影响其他模块，因为它们之间的接口(交互的平均值)没有改变。

高内聚性——把相似的东西放在一起。所以一个类应该有方法或行为来做相关的工作。举一个夸张的坏例子:List接口的实现不应该有与String相关的操作。String类应该有方法和与String相关的字段，类似地，List的实现应该有相应的东西。

希望这能有所帮助。

内聚性-所有事物之间的紧密联系。 耦合-所有事物如何相互连接。

让我们举个例子——我们想设计一辆自动驾驶汽车。

我们需要马达正常运转。

我们需要这辆车能自动行驶。

(1)中的所有类和函数都能很好地一起启动电机并使其运行，但不能帮助汽车转向。所以我们把这些类放在引擎控制器后面。

(2)中的所有类和函数都能很好地使汽车转向、加速和制动。它们不能帮助汽车启动或将汽油输送到活塞。所以我们把这些类放在它自己的驱动控制器后面。

这些控制器用于与所有可用的类和函数通信。控制器之间只进行通信。这意味着我不能从油门踏板类中调用活塞类中的函数来使汽车走得更快。

踏板类必须要求驱动控制器与引擎控制器对话，然后引擎控制器告诉活塞类加快速度。这使得我们程序员能够发现问题，并允许我们毫无顾虑地组合大型程序。这是因为代码都是在控制器后面工作的。