entity-framework - EntityFramework CodeFirst 中的限界上下文

Question

我搜索了很多关于有界上下文的信息，我知道这是领域驱动设计中的一种模式，它用于使用数据库上下文将我们的大型模型划分为更小的模型，但这让我有点困惑。事实上我不知道它到底是做什么的？以及使用这种模式有什么好处
请帮助我理解这种模式。

Answer 1

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

因此，您可能有资产 BC、仓储 BC、发票 BC、会计 BC 或 CRM BC。优点是您可以一次专注于一个领域。正确处理可能有点棘手，并且确定边界需要对各个领域有深入的了解，因此领域专家在完成这项工作方面是无价的。困难与确定聚合根相当。

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

Answer 2

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

假设您给旅行社打了电话，呼叫中心的接线员接听了您的电话，他/她可能会以“Dear Mr Doe”开头（想象这是您角色的名字：John Doe）他们之前和你的名字被记录并与你的电话号码绑定。

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

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

因此，无论订单如何，操作员都可以直接识别客户的姓氏。

另一方面，当我想预订机票时，运营商需要我的全名。提供的全名必须与我护照上的全名相同（以便我可以在机场办理登机手续）。机票预订系统使用以下模型：

上面的例子中有两个 PersonName ，当然你可以使用一个规范模型，但是这两个都不好用：

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

2）在机票预订中使用姓/名是没有意义的，因为只要它们与护照上的相同就没有关系。

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

之前有人告诉我：如果设计成通用的东西，它就不好用。

Answer 3

在一种普遍存在的语言是一致的情况下，就会出现有界上下文。

特定模型的限定适用性。边界上下文让团队成员对什么必须保持一致以及什么可以独立发展有一个清晰和共同的理解。

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

Answer 4

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

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

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

• 可读性
• 可扩展性
• 性能...和其他。