困惑有界的上下文和子域

我读过Eric Evan的书，现在正在读Vaughn Vernon的书。我在第二章谈到子域和有限的上下文，现在已经彻底搞糊涂了。

从我所能提炼出来的，BC和SD之间应该有1：1的关系。不过，我在其他地方读到，情况并非如此。

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

子域名是您业务的一部分。有核心领域，支持领域和通用领域。核心领域是资金的来源，支持领域支持你的核心业务，而通用领域是你需要的领域，但不关心很多，所以你可能会购买他们的架子。对于保险公司来说，核心领域是保险，支持领域可以是客户组合，而通用领域可以是时间表。

一般而言，有界的语境是无处不在的语言是一致的边界。在DDD walhalla中，每个子域都会生活在自己有界的环境中。但实际上，这是一种遗产，有一些包裹试图立刻做所有事情……这将迫使各种不协调的关系。

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

在DDD中，所有的东西都应该在无处不在的语言中进行沟通，所以技术团队和业务团队可以使用相同的术语，对问题有相同的看法

DDD中的领域代表着商业中真正的问题。如：电子商务是一个领域，工资系统是一个领域
域被分成许多子域，所以每个子域关注较小的问题。如：电子商务有许多子领域，如：购物车，计费，产品目录，客户信息…
每个子域都应该有明确的职责，所以它有一个限制它们function的边界，边界将有助于子域的重点只做一件事，做得很好。这个边界被认为是子域的有界上下文 。有界的上下文将定义：
- 子域需要多less域模型？
- 哪个属性需要在每个模型中？
- 子域需要哪些function？

例如：购物车子域需要模型：购物车，产品，客户信息…并包含在购物车上执行CRUD的function。注意：购物车子域中的产品和客户模型可能与产品目录和客户简档子域中的模型不同，它们只包含在购物车上显示的必要属性。

这篇文章也有帮助： http : //gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/