单个模块化组件应与其他组件协同工作(组件=模块)
本文关键字：组件 模块 协同工作 其他 模块化 单个 | 更新日期: 2023-09-27 18:01:14
我有一个问题，但我不知道如何正确描述，所以请仔细阅读。首先，让我们定义一下我眼中的模块这个术语：module=用于解决单个问题的一堆类、接口枚举(等等(。例如：
- 用于处理工作安排的模块
- 用于处理记账的模块
今天，我们的应用程序具有记账模块，旨在满足应用程序中的整个bokkepping需求
我们还有ModuleA，它生成的项目稍后应该在记账模块中使用，以便从中创建发票
因此，为了让这两个模块相互联系，我们实际上并没有将这两个模型都视为模型，并且每个模型都知道另一个模型的类
例如：
- 在记账模块中，如果我需要加载所有项目来创建发票，我会直接使用负责模块A中项目的类
- 为了跟踪模块A中有发票的项目，我将发票的id(发票与记账模块有关(存储在项目表中
正如你所看到的，这两个想要成为"模块"的人之间有着真正的联系。
现在我们有了另一个需求
我们还有模块B，我们需要将模块B也用于记账。但是，正如我之前所描述的，bookeeping只知道moduleA中的项目，并且只知道如何与它们交互。
我们如何使记账模块足够通用/模块化，以便我们也可以使用其他模块？假设我设法将模块A、模块B和记账分离开来，假设记账不知道其他模块。必须有了解所有模块的人才能连接它们！谁来连接模块B和记账？
我真的很了解可能的架构解决方案、图表和我应该知道的相关信息的链接。
非常感谢，Naor
如果我正确理解了这个问题，那么我相信你遇到的问题与有界上下文的DDD概念有关。您似乎有一个记账上下文和另一个可能触发记账事件的上下文。DDD解决这个问题的方法是为每个上下文创建一个不同的模型。例如，假设模块A是一个产品上下文，它包含待售产品的域模型。在这种背景下，有许多方面与产品、产品描述、定价等有关。具体而言，这种背景下的产品是实体。从记账上下文的角度来看，产品的概念表现为发票行项目。产品在记账上下文中唯一重要的方面是产品ID和开具发票时的价格。在这种情况下，产品很可能不是价值对象的实体。由于产品的概念对于每个上下文都是不同的，因此应该创建不同的模型。唯一共享的是产品ID，这样就可以知道记账上下文引用的是哪种产品。
以这种方式对系统进行分解可以解决当不同的上下文被限制在同一模型中时出现的许多其他问题。