我读过 Eric Evan 的书,现在正在读 Vaughn Vernon 的书。我在第二章中,他谈到了子域和有界上下文,现在完全糊涂了。
据我所知,BC 和 SD 之间应该存在 1:1 的关系。但是,我在其他地方读到不一定是这种情况。
有人可以向我解释一下 BC 和 SD 之间的关系吗?
我读过 Eric Evan 的书,现在正在读 Vaughn Vernon 的书。我在第二章中,他谈到了子域和有界上下文,现在完全糊涂了。
据我所知,BC 和 SD 之间应该存在 1:1 的关系。但是,我在其他地方读到不一定是这种情况。
有人可以向我解释一下 BC 和 SD 之间的关系吗?
子域是您业务的一部分。有核心域、支持域和通用域。核心域是钱的所在,支持域支持您的核心业务,而通用域是您需要的,但不太在意,因此您可能会立即购买它们。对于保险公司来说,核心领域是保险,支持领域可能是客户投资组合,通用领域可能是时间表。
通常,有界上下文是无处不在的语言一致的边界。在 DDD walhalla 中,每个子域都将存在于自己的有界上下文中。然而,在现实中,存在遗留问题,有些包试图一次完成所有事情......这将迫使各种尴尬的关系。
我试图用我的理解来解释这些概念。
在 DDD 中,一切都应该在通用语言下进行沟通,以便技术团队和业务团队可以使用相同的术语,对问题有相同的看法
例如:购物车子域需要模型:购物车、产品、客户信息……并包含在购物车上执行 CRUD 的功能。注意: Shopping Cart 子域中的 Product 和 Customer 模型可能与 Product Catalogs 和 Customer Profiles 子域中的模型不同,它们只是包含了在 Shopping Cart 上显示的必要属性。
Vaughn Vernon 在他的《实施领域驱动设计》一书中指出,“子领域存在于问题空间中,而有界上下文存在于解决方案空间中”</p>
想象一下正在开发支持牙医的软件。牙医有两个问题:修复患者的牙齿和为患者预约。修复牙齿是核心领域,预约是辅助子领域。在核心域中,医务人员关心患者的牙科病史,他们是否可以进行全身麻醉,他们目前的问题是什么等。在子域中,工作人员(不一定是医务人员)关心患者的联系信息,日期以及最适合医生和患者的时间、所需的牙科工作类型等。这两个领域都需要一个患者模型,但该模型将取决于我们为确保正确信息和解决每个域的问题时可用的功能。读https://robertbasic.com/blog/bounded-contexts-and-subdomains/
重读了 18 遍蓝皮书的 Booking Context 帮助我终于掌握了答案。http://codeidol.com/csharp/domain-driven-design/Maintaining-Model-Integrity/Bounded-Context/
这篇文章也有帮助: http: //gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/
请检查此链接,它会对您有所帮助,有界上下文或上下文?术语上下文是一组概念的一般描述,术语有界上下文更具体——有界上下文是应用程序的一个区域,它具有明确定义的边界,有自己的模型,并维护自己的代码。在有界上下文中,一切都应该严格一致。
通常,我们可以互换使用 Context 和 Bounded Context 这两个术语,尽管我倾向于用 Context 来谈论事物的业务方面,而术语 Bounded Context 则用于技术实现。
当两种不同的语言谈论相同或相似的事物时,该事物在 2 个不同的上下文中被引用。您可以在一定程度上在 2 个上下文中翻译该事物。
同样,一个术语在不同部门可能有不同的含义。在这种情况下,不同的上下文对该术语的解释不同。两者之间的翻译在某种程度上是可能的。
与其说“有界上下文”,不如试着说“有界世界”</p>
Vaughn Vernon 在他的《实施领域驱动设计》一书中指出:
“将子域与限界上下文一对一地对齐是一个理想的目标。” 第 57 页