我有一个问题，但我不确定如何正确描述，所以请仔细阅读。 首先，让我在我眼中定义术语模块： module =用于解决单个问题的一堆类，接口枚举（等等）。 例如：
今天，我们的应用程序具有bookkeepping模块，旨在满足应用程序中的整个bokkeepping需求。
我们还有ModuleA，它可以生成稍后在bookkeepping模块中使用的项目，以便从中创建发票。
因此，为了让这两个模块相互接触 - 我们实际上并没有将这两个模块视为模块，每个模块都知道其他模块的类。
例如：
正如你所看到的那样，这两个想要的“模块”之间存在真正的联系。
现在我们又有了另一个需求 我们也有moduleB，我们还需要使用moduleB和簿记。但是，正如我之前所描述的那样，bookeeping只知道来自moduleA的项目，并且知道如何与它们进行交互，并且只知道它们。
我们如何使簿记模块足够通用/模块化，以便我们可以使用其他模块？ 让我们假设我设法以某种方式分离moduleA，moduleB和簿记，并假设簿记不知道其他模块。必须有人知道所有模块才能在它们之间进行连接！谁将在moduleB和簿记之间建立联系？
我真正了解可能的架构解决方案，图表以及我应该知道的相关信息的链接。
非常感谢， NAOR
答案 0 :(得分：1)
如果我正确理解了这个问题，那么我相信你遇到的问题与bounded contexts的DDD概念有关。您似乎有一个簿记上下文和另一个可能触发簿记事件的上下文。解决此问题的DDD方法是为每个上下文创建不同的模型。例如，假设模块A是产品上下文，它包含待售产品的域模型。在此背景下，有许多方面与产品，产品描述，定价等有关。具体而言，此上下文中的产品为entities。从簿记上下文的角度来看，产品的概念表现为发票行项目。对于簿记环境而言，产品的唯一方面是产品ID和开票时的价格。 value objects在这种情况下，产品可能不是实体。由于产品的概念对于每个上下文都是不同的，因此应该创建不同的模型。唯一共享的是产品ID，以便可以知道簿记上下文引用了哪种产品。
以这种方式对系统进行保理可以解决当不同的上下文被限制在同一模型中时出现的许多其他问题。