上下文映射关系

Question

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

示例，BC为了将发布事件和库存BC将认购该事件，并在同一时间，库存BC可以发布事件和BC为了将认购

Answer 1

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

首先考虑您的限界上下文，在现实中，他们竟然一无所知对方，即使多个Contexts正在共同创造一个完整的解决方案，所有的上下文knows的是用户本身，OWN担忧。

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

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

因此，如果两种情况下，不应该彼此了解，但也许关心一些有关这两方面的信息，我们如何得到一个新的Employee已开始并需要支付的事实？

域事件

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

使用继承人它如何工作

1. 一个新员工开始，并添加到系统中OnboardingContext，一切都是正确的，该模型是成功的坚持。
2. 的OnboardingContext引发一个事件，就其而言是做该事件被称为NewEmployeeEvent

这就是它的OnboardingContext。它处理了新员工，保存了它，并且提出了一个非常漂亮的系统事件来说明发生了某件事（事件）。

我们的PayrollContext

1. 的PayrollContext有兴趣一对夫妇的事情，特别是要对了解一个新emplyee启动时。
2. 它签约的NewEmployeeEvent这个事件是一个普通型的，它不知道该事件源于，事实上它可能来自任何地方，但它感兴趣的数据的小袋子，或者在inormation事件。
3. 当事件引发此背景下handles这种情况下，在这种情况下，抓住有关薪酬与员工编号相关的信息，它坚持这给它自己的数据存储区中的工资以后使用。

景气完成。

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

当利益发生事情和事件引发的，任何人（上下文）感兴趣的是事件订阅，把手和做的事情要提供关于该事件的数据的。

那么你如何做到这一点？

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

你会遇到很多从吉米博加德文章（a better domain events pattern）和乌迪大寒（Domain Events Salvation）关于这个问题

看看nservicebus（支付）和masstransit（开放源代码），他们是太棒了盒子事件和消息传递系统。

Nservice总线在https://docs.particular.net/nservicebus/architecture/principles

Answer 2

是的，这是一个坏主意。

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

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

• 两个BC真的是单独的BC，还是他们应该是一个BC？
• 还是应该导致循环依赖的BC之一的一部分事实上在公元前三？

找到这些问题的答案在您的域的上下文可能会带你到一个更清洁的设计。