我已经读过Eric Evan的书，现在正在读Vaughn Vernon的书。我在第二章中，他谈论子域和有限的上下文，现在被彻底弄糊涂了。
从我的提炼中，BC和SD之间应该存在1：1的关系。但是，我在其他地方读到，不一定是这种情况。
有人可以向我解释BC和SD之间的关系吗？
Answers:
子域是您业务的一部分。有核心域，支持域和通用域。核心域名就是金钱所在，支持域名可以支持您的核心业务，而通用域名是您需要的，但并不在乎，因此您可能会直接购买。对于保险公司而言，核心领域是保险，支持领域可以是客户产品组合，而一般领域可以是时间表。
通常，有界上下文是普遍语言在其中保持一致的边界。在DDD walhalla中，每个子域都将生活在其自己的有界上下文中。但是实际上，存在着很多遗留物，有些软件包试图一次完成所有事情……这将迫使各种尴尬的关系。
我试图以我的理解来解释这些概念。
在DDD中，所有内容都应使用通用语言进行交流，以便技术团队和业务团队可以使用相同的术语并对问题有相同的看法
例如：“购物车”子域需要模型：购物车，产品，客户信息...，并包含在购物车上执行CRUD的功能。注意：Shopping Cart子域中的Product和Customer模型可能与Product Catalogs和Customer Profiles子域中的模型不同，它们仅包含要显示在Shopping Cart上的必要属性。
沃恩·弗农（Vaughn Vernon）在他的“实施领域驱动的设计”一书中指出，“子域生活在问题空间中，而解决方案空间中的边界上下文则存在”
想象一下正在开发的一种支持牙医的软件。牙医有两个问题：固定病人的牙齿和预约病人。固执己见是核心领域，任命是一个支持子领域。在核心领域，医务人员关心患者的牙科病史，是否可以进行全身麻醉，当前问题是什么，等等。在子领域中，医务人员（不一定是医务人员）关心患者的联系方式，日期以及最适合医生和患者的时间，所需的牙科工作的类型等。这两个领域都需要一个患者模型，但是该模型将取决于我们为确保正确信息和正确定位而使用的有限上下文。解决每个领域的问题时，可用的功能。读https://robertbasic.com/blog/bounded-contexts-and-subdomains/
请检查一下链接，它将对您有帮助，绑定上下文还是上下文？术语“上下文”是对概念分组的一般描述，术语“绑定的上下文”更具体-绑定的上下文是您的应用程序中具有明确定义边界，具有自己的模型并维护自己的代码的区域。在受限上下文中，所有内容都应严格一致。
通常，我们可以互换使用术语“上下文”和“绑定的上下文”，尽管我倾向于在上下文方面谈论事物的业务方面，在术语“绑定的上下文”方面谈论技术实现。