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

Question

我读过Eric Evan的书,现在正在阅读Vaughn Vernon的书.我在第二章中讨论了子域和有界的背景,现在我已经彻底混淆了.

从我能够提炼出来的情况来看,BC和SD之间应该存在1:1的关系.但是,我在其他地方读到这不一定是这种情况.

有人可以向我解释BC和SD之间的关系吗？

Answer 1

子域名是您业务的一部分.有核心域,支持域和通用域.核心领域是这些钱的,支持域支持您的核心业务,而通用域名是你需要的,但不很在意,所以你可能会买他们的架子.对于保险公司,核心域是保险,支持域可以是客户组合,通用域可以是时间表.

通常,有界上下文是普遍存在的语言一致的边界.在DDD walhalla中,每个子域都将存在于自己的有界环境中.然而,实际上,有遗产,有一些包试图一次做所有事情......这将迫使各种各样的尴尬关系.

Answer 2

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

在DDD中,一切都应该在无处不在的语言下进行,因此技术团队和业务团队可以使用相同的术语并对问题有相同的看法

• DDD中的域代表了业务中的真正问题.如:电子商务是一个域名,薪资系统是一个域名
• 域被分为许多子域,因此每个子域都关注较小的问题.如:电子商务有很多子域名,如:购物车,计费,产品目录,客户信息......
• 每个子域应该有明确的职责,因此它有一个限制其功能的边界,边界将帮助子域集中只做一件事并做得好.该边界被认为是子域的有界上下文.有界上下文将定义:
  • 子域需要多少个域模型？
  • 每个型号需要哪些属性？
  • 子域需要哪些功能？

例如:购物车子域需要型号:购物车,产品,客户信息......并包含在购物车上执行CRUD的功能.注意:购物车子域中的产品和客户模型可能与产品目录和客户配置文件子域中的模型不同,它们只包含要在购物车上显示的必要属性.

Answer 3

这是我的理解，我将使用医院示例来阐述概念，并深入探讨 BC 与子域有何不同，以及为什么它们之间没有 1:1 关系

例子

想象一下我们正在为一家医院制作软件，其中我们已经确定了 3 个子域

• 医疗保健（核心领域，他们实际上想要治愈患者）
• 发票（专注于发票的支持域）
• 知识（通用领域，医生维护如何对特定疾病的患者进行手术的程序）

现在我们知道有界上下文是边界，在这些边界下术语具有非常明确的含义。因此，让我们将它们应用到子域中

让我们考虑一下这个术语。Patient。当你听到“病人”这个词时，你会想到什么？

1. 他们目前的症状
2. 过去的医疗记录
3. 过敏

他们的账单支付信誉如何？目前未结余额？没想到吗？原因是您在 . 的核心子域空间中思考Health Care。仅当您转移到子域时，账单支付可信度才有意义Invoice。

我们从中了解到的是，“患者”术语位于有界上下文内，它是子域内的边界，在那里它具有非常特定的含义

其说的理由

BC 属于解决方案/实施/编程领域，而不是业务领域

是因为在这里我们决定哪些字段和行为应该成为患者模型的一部分

在核心域空间中，你可以Patient这样表示

    class Patient {
     
     List<Allergy> alergies;
     List<MedicalRecord> records;
     Age age;
    
     boolean isAllergicTo(Allergy allergy)
     boolean canTakeLocalAnesthesia()
    
    }

而在Invoicing子域中，您可能想像这样表示它

    class Patient {
     
     CreditCard creditCard;
     CreditScore creditScore;
     Bill currentBill;
    
     void charge(Amount amount)
    }

类似地，“健康核心”子域中的术语Cure将包含对患者进行的用于治愈疾病的操作，而在“健康核心”子域中，该术语Knowledge subdomain将包含与疾病相关的症状、诊断测试、处方建议等信息。

您现在可以看到医疗保健子域有多个 BC，并且在 BC 下每个术语都有非常具体的含义，从而支持通用语言

Answer 4

Vaughn Vernon 在他的“实施领域驱动设计”一书中指出“子领域存在于问题空间中，而有界上下文存在于解决方案空间中”

想象一下正在开发一个支持牙医的软件。牙医有两个问题：修复患者的牙齿和为患者预约。固牙是核心域，预约是辅助子域。在核心域中，医务人员关心患者的牙科病史，他们是否可以处理全身麻醉，他们当前的问题是什么等。在子域中，工作人员（不一定是医务人员）关心患者的联系信息、日期以及最适合医生和患者的时间、所需的牙科工作类型等。这两个领域都需要一个患者模型，但该模型将取决于我们为确保正确信息而设置的有界上下文和在解决每个领域的问题时，特征是可用的。读https://robertbasic.com/blog/bounded-contexts-and-subdomains/

Answer 5

第一的。蓝皮书的官方定义是：

• 领域：知识、影响力或活动的领域。

• 有界上下文：特定模型的有限适用性。有界上下文让团队成员对什么必须一致、什么可以独立开发有清晰和共同的理解。

请注意，在写下任何架构设计或代码行之前，这些概念本身就存在。

DDD 是指业务人员和程序员共享一种反映在源代码中的心理模型。但对于中型或大型组织来说，采用单一模型是不切实际的。最好分而治之，因为：

• 不同的地区有不同的需求、文化、行话等。有时同一概念有不同的术语，反之亦然。
• 召开一次大型会议来让人们达成一致的成本很高，而且对于这么多人来说，在如此规模的事情上达成一致真的很难。
• 开发企业级大型应用程序的认知负荷。最好实现可以分配给较小团队的组件。

因此，您可以将领域建模简化为特定的具体有界上下文。这样做的优点还在于降低了复杂性。但如果同一个概念在多个上下文中使用怎么办？这引出了第二个问题：

BC 和 SD 之间应该存在 1:1 的关系。然而，我在其他地方读到，情况不一定如此。

不，没有必要。以下是Martin Fowler 的示例：产品和客户子域由销售和支持限界上下文共享。

当然，您会尝试选择尽可能松散耦合的有界上下文。但就像当您在应用程序中分离模块时一样，存在最低程度的耦合来建立连接。因此，相同的概念在每个上下文中都有不同的建模方式（多个规范模型）。这可以通过添加在模型之间进行转换的反腐败层来在代码中实现。

迁移到单一有界上下文不仅仅是软件设计的问题。这需要改变企业的思维模式，而这很难。此外，人们有时对某个领域有更简单的看法，因为它降低了复杂性和认知负担。

具体例子：

在DDD Europe 的这次演讲中，他们举了一个来自 Amazon 的例子：

子域术语 Book 在不同的有界上下文中具有非常不同的模型：

• 在目录有界上下文中：图片、标题、作者、评级...
• 在运输范围内：尺寸、重量、国际限制
• 在有界上下文中搜索：全文内容、版权处理政策

因此，亚马逊可能有非常复杂的子域，具有很多属性：

• 书籍：isbn、书名、页数）
• 服装：尺码、颜色、材质
• 电脑：CPU、显卡、硬盘、内存

但只有其中一些与不同的子域相关。

让我添加一个带有更全局示例的图表

额外资源：

• Eric Evans 在 DDD Europe 2020 上的“限界上下文”演讲
• DDD Crew：回购资源
• 虚拟 DDD 社区

Answer 6

Rereading the Booking Context from the blue book 18 times helped me finally get a handle. http://codeidol.com/csharp/domain-driven-design/Maintaining-Model-Integrity/Bounded-Context/

This article helped as well: http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/