单个模块化组件应该与其他组件一起工作（组件=模块）
我有一个问题，但我不知道如何正确描述它，所以请仔细阅读。 首先，让我们定义一下我眼中的模块这个术语： 模块 = 一堆类、接口枚举（等等），旨在解决单个问题。 例如：
- 旨在处理工作安排的模块
- 旨在处理簿记的模块
今天，我们的应用程序有簿记模块，旨在处理应用程序中的整个簿记需求。
我们还有 ModuleA，它生成稍后应在簿记模块中使用的项目，以便从中创建发票。
因此，为了让这两个模块相互联系 - 我们实际上并没有将这两个模块视为模块，并且每个模块都知道来自另一个模块的类。
例如：
- 在簿记模块中，如果我需要加载所有项目才能创建发票，我直接使用负责 moduleA 中项目的类。
- 为了跟踪 moduleA 中具有发票的项目，我将发票的 id（发票与簿记模块相关）存储在 items 表中。
正如您所看到的，这两个想要的“模块”之间存在真正的联系。
现在我们有另一个需求。
我们还有 moduleB，并且我们还需要将 moduleB 与簿记一起使用。但是，正如我之前所描述的，记账只知道 moduleA 中的项目，并且知道如何与它们交互，并且只与它们交互。
我们怎样才能使簿记模块足够通用/模块化，以便我们也可以使用其他模块？ 假设我设法以某种方式分离 moduleA、moduleB 和 bookkeeping，并假设 bookkeeping 不知道其他模块。必须有人了解所有模块才能在它们之间进行连接！谁将连接 moduleB 和簿记？
我真的很欣赏可能的架构解决方案、图表和我应该知道的相关信息的链接。
非常感谢， 纳尔
I have a question but I am not sure how to describe it properly so please read carefuly.
First, lets define the term module in my eyes:
module = bunch of classes, interfaces enums (and so on) intended for solving single problem.
For example:
- module that intended to handle Working Arrangement
- module that intended to handle Bookkeeping
Today our application have bookkeepping module that intended to hanlde the whole bokkeepping need in the application.
We also have ModuleA that produces items that should be later used in the bookkeepping module in order to create invoices from them.
So, in order to let those two modules contact between each other - we actually didn't consider the both modules as modules and each module knows classes from the other module.
For example:
- In Bookkeepping module, if I need to load all the items in order to create invoice, I use directly the class responsible the items from moduleA.
- In order to follow items that have invoices in moduleA, I stored the id of the invoice (the invoice relates to bookkeeping module) in the items table.
As you can see there is a real bond betwen those two wannabe "modules".
Now we got another need.
We also have moduleB and we need to use moduleB also with the bookkeeping. But, as I described earlier, bookeeping only knows items from moduleA and know how to interact with them and only with them.
How can we make the bookkeeping module generic/modularic enough so that we can use other modules also with it?
Lets assume I manage to separate somehow moduleA, moduleB and bookkeeping, and lets assume bookkeeping doesn't know the other modules. There must be someone who knows all the modules in order to connect between them! Who will connect between moduleB and the bookkeeping?
I really appriciate possible architecture solutions, diagrams and links to relevant information I should know.
Thank you very much,
Naor
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我正确理解了这个问题，那么我相信您遇到的问题与 有界上下文。您似乎有一个簿记上下文和另一个可能触发簿记事件的上下文。解决这个问题的 DDD 方法是为每个上下文创建不同的模型。例如，假设模块 A 是产品上下文，它包含待售产品的域模型。在此上下文中，有许多与产品、产品描述、定价等相关的方面。具体来说，此上下文中的产品是实体< /a>.从簿记环境的角度来看，产品的概念表现为发票行项目。产品对簿记上下文唯一重要的方面是产品 ID 和开票时的价格。在值对象的上下文中，产品可能不是实体。由于产品的概念对于每个上下文都是不同的，因此应该创建不同的模型。唯一共享的是产品 ID，以便可以知道簿记上下文正在引用哪个产品。
以这种方式分解系统可以解决当不同的上下文被限制在同一模型中时出现的许多其他问题。
If I am understanding the question correctly then I believe the issue you are running into relates to the DDD concept of bounded contexts. It seems that you have a bookkeeping context and another context which may trigger bookkeeping events. The DDD way of solving this problem is to create a different model for each context. For example, suppose that Module A is a products context, it contains the domain model for products for sale. Within this context there are many aspects related to products, product descriptions, pricing, etc. Specifically, products in this context are entities. From the perspective of the bookkeeping context, the notion of product manifests itself as an invoice line item. The only aspects of a product that are important to the bookkeeping context are the product ID and the price at the time of invoicing. Products are likely not entities in this context by value objects. Since the notion of a product is different for each context, a different model should be created. The only thing shared is the product ID so that it can be known which product is being referred to by the bookkeeping context.
Factoring the system in this way solves many other problems which arise when disparate contexts are cramped into the same model.