3

我们的每个有界上下文都有一个事件消息处理器，它从上下文总线中提取消息并通过内存总线（反应式扩展，或https://github.com/flq/MemBus）在本地分派它。

在 DDD 书籍中，我读过它谈到将消息放入项目中的模块中，例如mycompany.accounts.infrastructure.messages和mycompany.ordering.infrastructure.messages.

对我来说有多个上下文的问题，引用这些消息会导致循环引用。

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

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

  2. 还是为将通过上下文总线的所有消息使用单独的共享库更好？

4

1 回答 1

1

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

  1. 一个用于合同（事件、异常、共享标识符等......）
  2. 一个用于执行实体。

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

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

  1. 合约的 BankName.FinancialAdvisory
  2. BankName.FinancialAdvisory.POCO 用于实现
  3. BankName.FinancialAdvisory.ORMOrOtherTechnologicalCouplingName 当我需要专门化某个类以在特定的技术环境中使用它们时。

然而，在 POCO 程序集中，根命名空间与合约的命名空间相同（例如 BankName.FinanicalAdvisory）：这是因为 POCO 以代码形式表达业务规则，无需任何技术关注，具有相同的合约开发生命周期。相反，包含技术专业化的程序集使用与程序集名称相同的根命名空间（例如 BankName.FinancialAdvisory.ORMOrOtherTechnologicalCouplingName）。

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

于 2013-03-27T09:36:40.810 回答