《实现领域驱动设计》拆书稿 - 第2章 领域、子域和限界上下文
2020-03-19 本文已影响0人
wiwisir
pic-09.jpeg
第2章：领域、子域和限界上下文
拆书稿
什么是领域（Domain）、子域、限界上下文？
-
领域（Domain）
即是一个组织所做的事情以及其中所包含的一切。
-
子域
业务系统的某个方面，我们将这些概念和功能用例如"核心域"、"子域"的名词将他们区分开。
-
限界上下文
将领域模型中的每一个数据都进行限界划分，把它们分别放在不同的上下文边界内。
子域 是一个抽象的概念，是指问题空间。按照解决问题的层面又可以分为：
- 核心域
- 支撑子域
- 通用子域
二、现实世界中领域和子域
领域包含：问题空间（problem space）和 解决方案空间（solution space）
- 问题空间：是核心域和其他子域的组合
需要思考的问题：
- 这个战略核心域的名字是什么，它的目标是什么？
- 这个战略核心域中包含哪些概念？
- 这个核心域的支撑子域和通用子域是什么？
- 如何安排项目人员？
- 你能组建出一支合适的团队吗？
- 解决方案空间：包括一个或多个限界上下文，即一组特定的软件模型
需要思考的问题：
- 有哪些软件资产是已经存在的，它们可以重用吗？
三、理解限界上下文
定义说明
限界上下文是一个显示边界，领域模型便存在于边界之内。在边界内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确地反映通用语言。
- 理解：同一个对象在不同限界上下文中，拥有不同的属性和行为。
例子
图书：对于一个图书出版机构，它需要处理图书生命周期的不同阶段。这些不同的阶段对应于不同的上下文环境，有如下：
- 概念设计，计划出书
- 联系作者，签订合同
- 管理图书的编辑过程
- 设计图书布局，包括插图
- 将图书翻译成其他语言
- 出版纸质版或电子版图书
- 市场营销
- 将图书卖给销售商或直接卖给读者
- 将图书发送给销售商或读者
哪些因素会导致我们创建不正确的限界上下文？
-
1、从技术层面而不是语义边界来考虑问题
使用平台、框架、基础设施或组件影响限界上下文设计
-
2、根据开发任务的分配来拆分限界上下文
不要为了管理技术资源而创建一些假（fake）的上下文边界。模块可以用来拆分开发者的任务职责，我们可以使用更加战术化的手段来管理团队的任务分配。一个团队，一个限界上下文。
读后思考
1、我们的问题空间是什么？它是由哪些战略核心域及其支撑子域组成？
2、团队工作分配和限界上下文如何结合？
- 将一个团队分配给一个限界上下文在我们公司里可行吗？会遇到哪些问题？
- 多个团队分配同一个限界上下文会遇到哪些问题？
- 在实际团队分配中结合限界上下文有没有更好的方式？
3、子域和限界上下文的关系是什么？
子域是问题域，限届上下文是解决方案域，子域的问题通过限界上下文解决。说实话，这个问题确实不好区分，太抽象，得在具体的实际项目中讨论才有意义，而且即使是在同一个项目中，不同人看问题的角度也是不一样的。
4、如何划分限界上下文？
很重要的一个点是要识别并去除二义性。那什么是二义性呢？
举个例子：儿子这个名词，在我家，儿子指的是我那上幼儿园的儿子；但是在我父母家，儿子代表的就是我自己。我家 和 我父母家，就是两个典型的限界上下文，当说"儿子"时，必须明确告知是在哪个家庭的上下文。这就是二义性。
