EntityFramework CodeFirst中的有界上下文

Question

我已经搜索了大量关于有界上下文的内容，我知道它是域驱动设计中的一种模式，它是使用数据库上下文将我们的大型模型划分为更小的模型，但这让我有点混乱。事实上我不知道它到底是做什么的？使用这种模式有什么好处
请帮我理解这种模式。

Answer 1

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

因此，您可能拥有Asset BC，Warehousing BC，Invoicing BC，Accounting BC或CRM BC。优点是您可以一次关注一个区域。要想做到这一点可能有点棘手，确定边界需要对各个领域有深入了解，因此领域专家在完成这项工作方面具有无可估量的价值。困难与识别聚合根源相同。

最大的好处是，如果你得到解耦正确，你的维护将变得更容易。这是正确的做法：）

Answer 2

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

想象一下，你打了一个旅行社的电话，呼叫中心的接线员接听了你的电话，他/她可能会回答＃34;亲爱的Doe先生＆＃34;（想象一下这是你的角色＆＃ 39;姓名：John Doe）如果您之前曾打过电话，并且您的姓名已被记录并与您的电话号码绑定。

几秒钟之后，我打电话给同一家旅行社，经营者回复了＆＃34;亲爱的周先生＆＃34;。

CRM告诉操作员我们的姓氏，但这里有一些棘手的问题：我是中国人，所以我的名字是周 hippoom（姓氏第一），但大多数西方名字都是姓氏最后（John Doe ）。为此，CRM使用以下模型：

因此，运营商可以发现客户＆＃39;姓氏直接，无论顺序如何。

另一方面，当我想预订机票时，操作员需要我的全名。 给出的全名必须与我护照上的全名相同（以便我可以在机场办理登机手续）。航空预订系统使用以下模型：

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

1）在CRM中使用fullname使操作员猜测哪一个是姓氏

2）在航空预订中使用姓氏/名字是没有意义的，因为只要它们与护照上的相同并不重要。

在这种情况下，有界上下文特定模型的效果更好：CRM.PersonName和AIR_BOOKING.PersonName

之前有人告诉过我：如果将其设计为通用的话，有些东西不容易使用。

Answer 3

在一种无处不在的语言是一致的情况下，出现了有限的语境。

  

特定模型的分隔适用性。界限背景   让团队成员清楚地了解必要的内容   一致的，什么可以独立发展。

阅读this article，它提供了一个有用的类比。

Answer 4

Julie Lerman对有界上下文提供了很好的解释。

我建议您阅读以下http://msdn.microsoft.com/en-us/magazine/jj883952.aspx

就n层架构（使用EF）而言，有界上下文有很多优点：

• 可读性
• 可伸缩性
• 性能 ......和其他人。