《实现领域驱动设计》拆书稿 - 第2章 领域、子域和限界上下文

pic-09.jpeg

第2章：领域、子域和限界上下文

拆书稿

什么是领域（Domain）、子域、限界上下文？

• 领域（Domain）

  即是一个组织所做的事情以及其中所包含的一切。

• 子域

  业务系统的某个方面，我们将这些概念和功能用例如"核心域"、"子域"的名词将他们区分开。

• 限界上下文

  将领域模型中的每一个数据都进行限界划分，把它们分别放在不同的上下文边界内。

子域 是一个抽象的概念，是指问题空间。按照解决问题的层面又可以分为：

• 核心域
• 支撑子域
• 通用子域

二、现实世界中领域和子域

领域包含：问题空间（problem space）和 解决方案空间（solution space）

• 问题空间：是核心域和其他子域的组合

需要思考的问题：

• 这个战略核心域的名字是什么，它的目标是什么？
• 这个战略核心域中包含哪些概念？
• 这个核心域的支撑子域和通用子域是什么？
• 如何安排项目人员？
• 你能组建出一支合适的团队吗？

• 解决方案空间：包括一个或多个限界上下文，即一组特定的软件模型

需要思考的问题：

• 有哪些软件资产是已经存在的，它们可以重用吗？

三、理解限界上下文

定义说明

限界上下文是一个显示边界，领域模型便存在于边界之内。在边界内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确地反映通用语言。

• 理解：同一个对象在不同限界上下文中，拥有不同的属性和行为。

例子

图书：对于一个图书出版机构，它需要处理图书生命周期的不同阶段。这些不同的阶段对应于不同的上下文环境，有如下：

• 概念设计，计划出书
• 联系作者，签订合同
• 管理图书的编辑过程
• 设计图书布局，包括插图
• 将图书翻译成其他语言
• 出版纸质版或电子版图书
• 市场营销
• 将图书卖给销售商或直接卖给读者
• 将图书发送给销售商或读者

哪些因素会导致我们创建不正确的限界上下文？

• 1、从技术层面而不是语义边界来考虑问题

  使用平台、框架、基础设施或组件影响限界上下文设计

• 2、根据开发任务的分配来拆分限界上下文

  不要为了管理技术资源而创建一些假（fake）的上下文边界。模块可以用来拆分开发者的任务职责，我们可以使用更加战术化的手段来管理团队的任务分配。一个团队，一个限界上下文。

读后思考

1、我们的问题空间是什么？它是由哪些战略核心域及其支撑子域组成？

2、团队工作分配和限界上下文如何结合？

• 将一个团队分配给一个限界上下文在我们公司里可行吗？会遇到哪些问题？
• 多个团队分配同一个限界上下文会遇到哪些问题？
• 在实际团队分配中结合限界上下文有没有更好的方式？

3、子域和限界上下文的关系是什么？

子域是问题域，限届上下文是解决方案域，子域的问题通过限界上下文解决。说实话，这个问题确实不好区分，太抽象，得在具体的实际项目中讨论才有意义，而且即使是在同一个项目中，不同人看问题的角度也是不一样的。

4、如何划分限界上下文？

很重要的一个点是要识别并去除二义性。那什么是二义性呢？

举个例子：儿子这个名词，在我家，儿子指的是我那上幼儿园的儿子；但是在我父母家，儿子代表的就是我自己。我家 和 我父母家，就是两个典型的限界上下文，当说"儿子"时，必须明确告知是在哪个家庭的上下文。这就是二义性。

推荐阅读

1. DDD实施过程中的点滴思考