Entity framework EntityFramework CodeFirst中的有界上下文

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

---

请帮助我理解这个模式

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

因此，您可能有资产BC、仓储BC、开票BC、会计BC或CRM BC。优点是你可以一次专注于一个领域。这可能有点棘手，要正确确定边界需要对各个领域有深入的了解，因此领域专家在完成这项工作时是非常宝贵的。难度与识别总根一致。

---

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

当一种普遍存在的语言是一致的时，就会产生一个有界的上下文

特定模型的限定适用性。边界上下文 让团队成员清楚地了解必须做的事情 一致性和可独立开发的内容

---

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

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

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

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

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

因此，无论订单如何，运营商都可以直接识别客户的姓氏

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

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

1） 在CRM中使用全名可以让操作员猜测哪一个是姓氏

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

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

---

以前有人告诉我：如果它被设计成通用的，那么它就不容易使用。

朱莉·勒曼（Julie Lerman）对有界上下文提供了一个很好的解释

我建议你阅读以下内容

就n层体系结构（带EF）而言，有界上下文有很多优势：

• 可读性
• 可伸缩性
• 演出 …和其他人

什么是“使用数据库上下文”？我不认为绑定上下文与特定的基础设施技术绑定，比如EntityFramework，您能提供更多细节吗？