干净的体系结构-“组件原理三合一”的示例

我正在阅读Clean Architecture的“组成原则”部分。

作者在那里解释了组件设计的三个原理。我想我有点孤立地了解它们。

重用/发布等效原则（REP）
我对此的理解是，要使软件包可重用，它们需要具有适当的发行跟踪机制（版本，文档等）

通用闭包原理（CCP）
该声明指出，出于相同原因而更改的类必须捆绑在同一包中。目标是实现可维护性->如果您的应用程序中的某些内容发生更改，则可能会在单个软件包（或仅几个软件包）中进行更改。

通用重用原则（CRP）
如果用户依赖于某个程序包，则他们应该依赖于该程序包中的所有类。
这意味着，程序包应仅包含可一起重用的那些类。

在研究了这些原理之后，作者展示了这些原理的“三合一”，类似于经典的CAP定理：

我对此的理解是，在设计组件时，您只能选择遵循三个原则中的两个。

那是我不太了解的部分：

我看不出使用REP是如何独占其他任何原理。据我了解，满足REP意味着实施发布管理机制。我看不到同时坚持CCP和CRP可以禁止这样做吗？
如何将CCP和CRP一起使用？我认为它们是完全相反的原则。前者指出，类应以可以一起更改的方式分组，而后者则应将类以一起使用的方式分组。我认为这两个目标是相反的，我看不到如何共同实现。

如果有人帮助揭穿这些原则，将感到很高兴，因为这本书没有任何可能的“三合会”对的实际例子。 REP和CRP，REP和CCP，CCP和REP。

如果有人可以提供这些可能的配对的缺失示例，那就太好了！

通用闭包原理：不要使应用程序中的组件过于宽泛。

倾向于一起更新的组件应该组合在一起。如果在进行一项更改时许多组件需要更新，则组件之间可能存在耦合。随着组件之间耦合程度的提高，由于意外的用例和不完善的文档，对一个组件进行细微更改而产生广泛影响的可能性也会增加。

通用重用原则：不要使应用程序中的组件过于具体。

如果组件的用户需要一个组件的一部分，则应包括该组件的所有部分（因为它们是相关的/必要的）。从用户的角度来看，组件应该做一件事。建立“一件事”的所有逻辑都应包含在组件中。将逻辑打包到组件中的主要好处是可以提高可用性和可维护性，并且复用单元应该是有用的复用单元。

重用/发布等效原则：不要以为组件是完美的。

手动传递单个类是无法维持的。为了使给定的组件有用，必须有一种提供长期稳定性的机制（例如：已注意到的问题已解决，等等）。因此，应该有某种形式的发布流程，可以记录问题并可以找到和使用组件的更新版本。

从可用性和可维护性的角度确定给定组件的特定性/广泛性时，必须考虑取舍。

需要权衡取舍，但与CAP相比似乎有些困难。 CAP更像是“挑剔”，而更像是“记住编写组件的原因”。我倾向于认为存在一些主观的最优结构，这些结构提供了可用且值得信赖的组件。 CAP客观上只能选择2个。