Domain driven design 跨边界上下文事件-存储消息契约的模块/项目

我们的每个有界上下文都有一个事件消息处理器，它从上下文间总线中提取消息，并通过内存总线（反应式扩展，or）在本地分派消息

在DDD书籍中，我读到它谈到将消息放入项目中的模块中，例如

mycompany.accounts.infrastructure.messages

和

mycompany.ordering.infrastructure.messages

对于我来说，在多个上下文中引用这些消息会导致循环引用

如何最好地组织不同的有界上下文消息传递契约：

每个有界上下文是否都有一个单独的项目，其中包含该上下文的所有可能消息，以便其他有界上下文可以引用

或者，对于将通过上下文间总线传递的所有消息，使用单独的共享库更好吗

---

我解决了类似的问题，为每个有界上下文构建（至少）两个程序集：

一个用于合同（事件、例外、共享标识符等…）

一个用于实体的实施

这样，不同的有界上下文实现可以引用相同的契约，而无需任何循环

编辑
至于命名约定，例如，我通常以有界上下文的“常规名称”命名程序集

BankName.FinancialAdvisory用于合同

BankName.FinancialAdvisory.POCO用于实施

当我需要专门化某个类以在特定的技术环境中使用它们时，请使用BankName.FinancialAdvisory.ORMOrOtherTechnologicalCouplingName

但是，在POCO程序集中，根命名空间与契约的命名空间相同（例如BankName.FinanicalAdvisory）：这是因为POCO在代码中表达业务规则而不涉及任何技术问题，具有与契约相同的开发生命周期。相反，包含技术专门化的程序集使用与程序集名称相等的根命名空间（例如BankName.FinancialAdvisory.ORMOrOtherTechnologicalCouplingName）

---

然而，与域相关的所有程序集都共享相同的命名空间结构：例如，如果BankName.FinancialAdvisory下存在命名空间“Funds”，则它也同时存在于POCO和ORMOrOtherTechnologicalCouplingName中（当然，如果它包含任何类）.

谢谢-有关于名称空间的建议吗？我只是想回顾一下我今天看到的，非常有趣，一个不同的观点，即我们对消息传递更为开放，而不是具体的合同类型-您的回答肯定非常有帮助，因为它清楚地显示了如果您希望更紧密地耦合，如何链接项目