Domain driven design 对有界上下文和子域感到困惑

我读过埃里克·埃文的书，现在正在读沃恩·弗农的书。我在第二章，他谈到了子域和有界上下文，现在我完全搞糊涂了

根据我所能提取的，BC和SD之间应该是1:1的关系。然而，我在其他地方看到，情况未必如此

---

有人能给我解释一下BC和SD之间的关系吗？

重新阅读蓝皮书中的预订上下文18次，我终于找到了答案

---

这篇文章也很有帮助：

子域是您业务的一部分。有核心域、支持域和通用域。核心域名是赚钱的地方，支持域名支持你的核心业务，通用域名是你需要的，但你不太在乎，所以你可能会买现成的。对于保险公司来说，核心领域是保险，支持领域可以是客户投资组合，通用领域可以是类似时间表的东西

---

一般来说，有界语境是普遍存在的语言保持一致的边界。在DDD walhalla中，每个子域将生活在自己的有界上下文中。然而，在现实中，也有一些遗留问题，有些软件包试图一次完成所有事情。。。这将迫使所有类型的awkard关系。

我试图用我的理解来解释这些概念

在DDD中，所有内容都应该用通用语言进行沟通，这样技术团队和业务团队就可以使用相同的术语并对问题有相同的看法

• DDD中的域代表了业务中真正的问题。例如：电子商务是一个领域，工资系统是一个领域
• 域被划分为许多子域，因此每个子域关注较小的问题。例如：电子商务有许多子域，如：购物车、账单、产品目录、客户信息
• 每个子域都应该有明确的职责，因此它有一个限制其功能的边界，该边界将帮助子域专注于只做一件事，并且做得很好。此边界被视为子域的有界上下文。有界上下文将定义：
  • 子域需要多少域模型
  • 每个模型中需要哪些属性
  • 子域中需要哪些功能

购物车子域需求模型：购物车、产品、客户信息。。。并包含在购物车上执行CRUD的函数。注意：购物车子域中的产品和客户模型可能与产品目录和客户配置文件子域中的模型不同，它们只包含在购物车上显示的必要属性。

请检查链接，它将帮助您， 有界语境还是有界语境？ 术语上下文是一组概念的一般描述，术语有界上下文更为具体–有界上下文是应用程序的一个区域，它有明确定义的边界，有自己的模型，并维护自己的代码。在有限的上下文中，所有内容都应该严格一致

---

通常，我们可以交替使用术语上下文和有界上下文，尽管我倾向于从上下文的角度谈论事物的业务方面，而术语有界上下文则是关于技术实现。

Vaughn Vernon在其《实现领域驱动设计》一书中指出“子域位于问题空间中，而有界上下文位于解决方案空间中”

设想一个正在开发的支持牙医的软件。牙医有两个问题：固定患者的牙齿和为患者预约。固定牙齿是核心领域，预约是辅助子域。在核心领域，医务人员关心患者的牙科病史，他们能处理一般问题吗麻醉与否，他们目前的问题是什么，等等。在子领域的工作人员（不一定是医务人员）关心患者的联系信息、最适合医生和患者的日期和时间、所需牙科工作的类型等。这两个领域都需要一个患者模型，但该模型将取决于我们设置的有限上下文，以确保在解决each域。

---

阅读

Vaughn Vernon在其《实施领域驱动设计》一书中指出：

“将子域与有界上下文一一对应是一个理想的目标。”第57页

---

也许解释BC和SD之间的区别会很有帮助，但是如果你从文章中复制回答问题的内容，那就太好了！下面是第二篇文章的总结：子域定义域并存在于问题空间中。有界上下文定义域模型并存在于解决方案空间中理想情况是子域和有界上下文之间完全一致，但在实践中，在这方面必须接受一定程度的灵活性。不同意gorodinksi链接，因为他在技术意义上讲得太多，在商业意义上讲得不够。@JefClaes的答案要好得多。如果子域生活在其中，第一个链接似乎断开了s自己的有界上下文，它意味着有界上下文比子域更宽。但是从我从沃恩·弗农的书中得到的，在子域中你可以有多个有界上下文。所以说每个BC都存在于它的SD中可能更正确。我错了吗？