separation-of-concerns - “耦合”是否仅与代码相关，或者该术语可以应用于软件组件和架构？

Question

例如，在讨论构建或部署过程时，要确保它独立于 IDE。这是“耦合”，还是被认为是关注点分离，还是完全不同的东西？一般概念是在流程或架构中引入最少数量的变量，以便在发生故障时，显着降低识别可能故障点的难度。有其他定义吗？

Answer 1

完全不同的东西。

耦合是代码。

独立工具只是独立工具。

微软让我相信独立工具是个坏主意。他们告诉我，一个供应商的集成工具套件是一件好事。

Answer 2

我将耦合描述为与运行时系统稳定性或系统变化有关的东西。

在考虑稳定性时，如果一个组件的故障导致其他组件的故障，耦合就会出现。例如，如果两个软件组件直接通过 TCP 连接进行通信，那么一个组件的故障意味着另一个组件无法工作。整个系统都瘫痪了。如果我通过允许两个组件通过消息队列进行通信来解耦（例如），那么每个组件可能会在没有另一个组件的情况下继续独立工作（假设这在应用程序中有意义）。

在考虑系统更改时，当一个模块中的代码更改意味着我必须去更改大量其他模块中的代码时，耦合就会出现。

您使用构建/部署工具给出的示例是一种耦合形式，但并不是人们在考虑运行时和代码耦合等架构问题时真正想到的。