2

2个有界上下文可以在它们之间进行上游通信是否被认为是一个坏主意？

例如，订单 BC 将发布事件，库存 BC 将订阅该事件，同时库存 BC 可以发布事件，订单 BC 将订阅

4

2 回答 2

3

不，这不是一个坏主意，事实上这是一个好主意，让我解释一下。

首先考虑你的有界上下文，实际上他们应该对彼此一无所知，即使当多Contexts个人一起工作以创建一个完整的解决方案时，所有上下文都是knows关于它自己的，它的OWN关注点。

负责OnboardingContext新员工何时在公司开始工作，这里Employee是第一次将实体添加到系统中。在这里，员工有姓名、电话号码、开始日期、地址、婚姻状况等。

考虑一下PayrollContext，它也有一个Employee实体，但这里这个实体只有一个 ID、一个薪水、开始日期和结束日期 - 这里它不关心地址或婚姻状况，它甚至不一定关心名称，因为在此上下文中名称并不重要，只有薪水、开始日期和结束日期。

因此，如果这两个上下文不应该相互了解，但可能关心与两者相关的一些信息，我们如何获得一个新的Employee已经开始并且需要获得报酬的事实？

领域事件

域事件与分布式系统一起使用。该模型当然会变得更复杂，但也更具可扩展性。领域事件用于事件驱动架构

这是它的工作原理

  1. 新员工启动并添加到系统中OnboardingContext，一切正常，模型成功持久化。
  2. 引发一个事件，该OnboardingContext事件被调用NewEmployeeEvent

就OnboardingContext它而言，这就是它的完成。它处理了新员工，保存了它，并引发了一个漂亮的系统范围的事件，表明发生了某事（事件）。

现在到PayrollContext

  1. 他们PayrollContext对几件事感兴趣，特别是它想知道新员工何时开始。
  2. 它订阅的NewEmployeeEventthis 事件是一个普通类型，它不知道该事件来自哪里，实际上它可能来自任何地方，但它对一小包数据或有关该事件的信息感兴趣。
  3. 当事件在该事件的上下文中引发时handles，在这种情况下，获取有关薪水和员工编号的相关信息，它会将其保存到自己的数据存储中，以供稍后在工资核算期间使用。

繁荣完成。

你的系统现在监听并响应事件，这些事件在你的系统中流动，在任何方向，在所有方向。

当感兴趣的事情发生并引发事件时，对该事件感兴趣的任何人（上下文）都会订阅、处理并使用与该事件相关的数据做任何事情。

那么你是怎么做到的呢？

有很多阅读要做，只是谷歌 DDD 和领域事件。

您会看到 Jimmy Bogard（更好的领域事件模式）和 Udi Dahan（领域事件拯救）关于该主题的大量文章

看看nservicebus（付费）和masstransit（开源），它们是开箱即用的事件和消息传递系统。

Nservice bus 在https://docs.particular.net/nservicebus/architecture/principles上有一些关于该主题的精彩视频

于 2016-11-11T01:36:28.990 回答
2

是的，这是个坏主意。

您的设计将导致两个 BC 之间的循环依赖。与软件开发的许多其他领域一样，循环依赖几乎总是一个坏主意。

如果您的用例迫使您这样做，那么您应该重新考虑您的上下文映射。问自己以下问题：

  • 两个 BC 真的是独立的 BC，还是应该合二为一？
  • 或者导致循环依赖的 BC 的一部分实际上应该在第三个 BC 中？

在您的领域中找到这些问题的答案可能会引导您进行更简洁的设计。

于 2016-10-01T12:18:16.003 回答