EntityFramework CodeFirst中的有界上下文

Question

我已经搜索了很多关于有界上下文的内容，我知道它是领域驱动设计中的一种模式，它是用来使用数据库上下文将我们的大模型划分成更小的模型，但它让我有点困惑。实际上我不知道它到底是干什么的？使用这种模式的好处是什么？

请帮助我理解这个模式。

Answer 1

有界上下文不一定是将大型模型分解为较小的模型，而是用于识别业务中的不同域模型。每个BC都应该有自己的数据存储区。BC可以以各种方式(反腐败层、值对象)使用来自另一个BC的数据。

因此，您可能有资产BC、仓储BC、Invoicing、会计BC或CRM BC。优点是你可以一次专注于一个领域。要正确处理和识别边界可能有些棘手，这需要对各个领域有很好的了解，因此领域专家在完成这一任务时是非常宝贵的。困难就像识别聚集根一样。

最大的好处是，如果您得到解耦校正，您的维护将更容易。这是正确的做法:)

Answer 2

我举一个例子，因为其他人已经给出了很好的解释。

假设你打了一个电话给旅行社，呼叫中心的接线员接了你的电话，他/她可能会回答“亲爱的Doe先生”(假设这是你角色的名字:John Doe)，如果你之前打过电话，并且你的名字被记录下来并与你的电话号码绑定在一起。

几秒钟后，我给同一家旅行社打了个电话，接线员接上“亲爱的周先生”。

客户关系管理告诉运营商我们的姓氏，但这里有一些棘手的问题:我是一个中国人，所以我的名字是周河马(姓第一)，但大多数西方名字都是姓最后(约翰Doe)。考虑到这一点，CRM使用了以下模型：

​

​

因此，运营商可以直接发现客户的姓氏，无论订单。

另一方面，当我想订机票时，接线员需要我的全名。给出的全名必须与护照上的全名相同(以便我可以在机场办理登机手续)。航空订票系统采用以下模式：

​

​

在上面的示例中有两个PersonName，您当然可以使用一个规范模型，但这对它们都不容易使用：

1)在CRM中使用全名使操作者猜出哪一个是姓

2)在航空订票时使用姓/名是没有意义的，因为只要他们和护照上的姓/名一样，就不重要了。

在这个case:CRM.PersonName和AIR_BOOKING.PersonName中，有界上下文特定的模型工作得更好。

以前有人告诉我:如果某些东西被设计成通用的话，它是不容易使用的。

Answer 3

当一种无处不在的语言是一致的时，就会产生有界的上下文。

特定模型的限定适用性。边界上下文使团队成员清楚和共享地理解哪些内容必须一致，哪些内容可以独立发展。

阅读这篇文章，它提供了一个有用的类比。