domain-driven-design - 上下文映射 - 关系

Question

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

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

Answer 1

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

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

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

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

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

领域事件

域事件用于分布式系统。该模型当然会变得更复杂，但也更具可扩展性。域事件用于 event driven architecture

这是它的工作原理

1. 一名新员工开始工作并在 OnboardingContext 中添加到系统中，一切正确，模型成功持久化。
2. OnboardingContext引发事件，该事件称为 NewEmployeeEvent

OnboardingContext 就这些了就它而言，它已经完成了。它处理了新员工，保存了它，并引发了一个漂亮的系统范围事件来说明某事(一个事件)已经发生。

现在到 PayrollContext

1. PayrollContext对几件事感兴趣，特别是它想知道新员工何时开始工作。
2. 它订阅了NewEmployeeEvent此事件属于普通类型，它不知道事件来自何处，事实上它可能来自任何地方，但它对一小袋数据或有关该事件的信息感兴趣。
3. 当此上下文引发事件时 handles该事件(在本例中是获取有关工资和员工编号的相关信息)将其保存到自己的数据存储中，以供稍后在工资核算期间使用。

繁荣完成。

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

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

那么你是怎么做到的呢？

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

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

看看nservicebus (付费)和 masstransit (开源)它们是非常棒的开箱即用事件和消息系统。

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