上下文映射 - 关系

Question

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

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

Answer 1

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

首先考虑一下你有限的上下文，实际上他们应该对彼此一无所知，即使多个Contexts正在共同创建一个完整的解决方案，所有上下文knows关于它本身，它的< em> OWN 关注点。

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

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

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

域名活动

域事件与分布式系统一起使用。当然，模型将变得更加复杂，但也更具可扩展性。域事件用于event driven architecture

继承人如何运作

1. 新员工启动并在OnboardingContext中添加到系统中，一切正确且模型已成功保留。
2. OnboardingContext举起一个事件，该事件被称为NewEmployeeEvent

就OnboardingContext而言，只要关注它就完成了。它处理了新员工，保存了它，并提出了一个非常棒的系统事件来说明发生了某件事（事件）。

现在到PayrollContext

1. PayrollContext对一些事情很感兴趣，特别是它想要知道一个新的emplyee何时开始。
2. 它订阅NewEmployeeEvent这个事件是一个常见的类型，它不知道事件的来源，事实上它可能来自任何地方，但它对一小块该事件的数据或信息。
3. 当事件被提出时，此事件handles该事件，在这种情况下抓取有关工资和员工编号的相关信息，它会将此持久保存到它自己的数据存储中，以便稍后在工资单中使用。< / LI> 忙完了。

   您的系统现在可以监听并响应事件，这些事件可以在整个系统中，任何方向，向各个方向流动。

   当感兴趣的事情发生并且事件被提出时，对该事件感兴趣的任何人（上下文）都会订阅，处理并执行它想要的与该事件相关的数据。

   那你怎么做？

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

   你会看到Jimmy Bogard（a better domain events pattern）和Udi Dahan（Domain Events Salvation）关于这个主题的很多文章

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

   Nservice巴士在https://docs.particular.net/nservicebus/architecture/principles

   上有一些关于这个主题的精彩视频

Answer 2

是的，这是一个坏主意。

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

如果您的用例强迫您执行此操作，则应重新考虑您的上下文地图。问自己以下问题：

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

在您的域名中找到这些问题的答案可能会让您获得更清晰的设计。