单个模块化组件应与其他组件一起使用（组件=模块）

Question

我有一个问题，但我不确定如何正确描述它，所以请仔细阅读。 首先，让我们在我的眼中定义术语模块： 模块 = 用于解决单个问题的一堆类、接口枚举（等等）。 例如：

• 用于处理工作安排的模块
• 用于处理簿记的模块

今天我们的应用程序有记账模块，旨在处理应用程序中的整个记账需求。
我们还有 ModuleA 生成的项目，以后应该在簿记模块中使用，以便从中创建发票。
因此，为了让这两个模块相互联系 - 我们实际上并没有将这两个模块视为模块，并且每个模块都知道另一个模块的类。
例如：

• 在 Bookkeepping 模块中，如果我需要加载所有项目以创建发票，我直接使用负责模块 A 中项目的类。
• 为了跟踪模块A中有发票的项目，我将发票的ID（发票与簿记模块相关）存储在项目表中。

如您所见，这两个想要的“模块”之间存在真正的联系。

现在我们有了另一个需求。
我们也有 moduleB，我们还需要将 moduleB 与簿记一起使用。但是，正如我之前所描述的，bookeeping 只知道 moduleA 中的项目，并且知道如何与它们交互并且只与它们交互。

我们如何使簿记模块足够通用/模块化，以便我们也可以使用其他模块？ 假设我设法以某种方式将模块 A、模块 B 和簿记分开，并假设簿记不知道其他模块。必须有人知道所有模块才能连接它们！模块 B 和簿记之间由谁来连接？

我真的很喜欢可能的架构解决方案、图表和指向我应该知道的相关信息的链接。

非常感谢， 诺尔

Answer 1

如果我正确理解了这个问题，那么我相信您遇到的问题与 bounded contexts 的 DDD 概念有关。似乎您有一个簿记上下文和另一个可能触发簿记事件的上下文。解决这个问题的 DDD 方法是为每个上下文创建不同的模型。例如，假设模块 A 是一个产品上下文，它包含待售产品的域模型。在此上下文中，有许多方面与产品、产品描述、定价等相关。具体而言，此上下文中的产品为entities。从簿记上下文的角度来看，产品的概念表现为发票行项目。对簿记上下文重要的产品的唯一方面是产品 ID 和开票时的价格。 value objects 在这种情况下，产品可能不是实体。由于每种情况下产品的概念都不同，因此应该创建不同的模型。唯一共享的是产品 ID，以便可以知道簿记上下文引用了哪个产品。

以这种方式分解系统可以解决许多其他问题，这些问题在不同的上下文被限制在同一个模型中时会出现。