领域驱动设计学习记录目录
领域（Domain）
理解领域
领域的概念很好理解，就是一个组织所做的事情以及其中所包含的一切（如果这个组织设计多业务系统，这里只是指其中的一个业务系统）。
主要包含两个概念：
- 业务范围内的一切事物。（也就是能找到的名词）
- 在业务范围内进行的活动。（也就是能找到的动词）
领域的歧义
因为领域既可以表示整个业务系统，也可以表示其中的某一个核心域或者支撑子域，所以在涉及业务系统的某一方面的时候，最好直接用核心域以及核心子域来表示。
领域模型
领域模型并不是为整个领域进行构建的模型，而是为某一个子域构建的模型。
子域
子域是什么
一个例子：在一个零售商系统中，需要展示不同类别的产品，允许买家下单和付款，还需要安排物流。 则这个零售商系统中，可以分出4个主要的子域：
- 产品目录
- 订单
- 发票
- 物流
子域的特点
- 子域是领域的拆分，一个领域会被拆分成多个子域，有核心域、支撑子域、通用子域。
- 子域并不一定要做得很大，并且包含很多功能。（例如，只包含一套算法的子域，这个子域可以以模块的方式从核心域中分离出来）。
核心域
核心域是业务领域的一部分，是业务成功的主要促成因素。也就是说，是否是核心域取决于这个子域的业务价值。
支撑子域
支撑子域对应系统的某些重要方面，但是不属于核心。
通用子域
通用子域被用于整个业务系统，提供一些支持。
限界上下文
概要
限界上下文可以看成是一个范围，在这个范围中，所有用到的领域术语、词组或句子都有明确的含义。
通常我们会希望将子域和限界上下文进行一一对应。这样能将领域模型分离到不同的业务板块中去。当然要实现这一点，会很困难。
为什么要有限界上下文
每一个模型，包括它的属性和操作，在限界上下文的边界之内都是具有特殊含义的。
用一个例子来说明限界上下文的作用，一个图书出版机构需要处理图书生命周期的不同阶段，每个阶段对应不同的上下文：
- 概念设计，计划出书
- 联系作者，签订合同
- 管理图书的编辑过程
- 设计图书布局，包括插图
- 将图书翻译成其他语言
- 出版纸质版或电子版图书
- 市场营销
- 将图书卖给销售商或直接卖给读者
- 将图书发送给销售商或读者
在每个阶段中，虽然同样叫做”图书”，但是却在每个上下文中都需要建立不同模型。
- 一本书只有在和作者签订了合同后才拥有书名，书名可能在编辑过程中进行修改。
- 在编辑过程中，图书包含一系列的稿件，其中包括注释和校正，以及最终稿件。
- 页面布局由专门的图形设计师完成。
- 市场营销人员只需要知道图书的简介。
- 对于图书的销售及物流，需要的是图书的标识码、物流目的地、数量、重量等。
由于行为和需要的属性都完全不同，我们需要在每一个限界上下文中都进行book的建模。而这些不同的book对象共享一个标识。
限界上下文包含什么
- 模型，模型是限界上下文的一等公民
- 数据库Schema（前提是模型驱动着数据库的Schema设计，也就是建模人员会进行设计、开发和维护）
- 用户界面（如果该用户界面会驱动着模型的设计）
- 应用服务
限界上下文的大小
只要足够包含核心领域内的概念即可。
也就是说不应该遗漏一些概念，也不应该包含外部概念。
从技术上看限界上下文
- 在IDEA中，一个project就是一个限界上下文。
- 对于Java package来说，一个顶层模块就是一个限界上下文（com.mycompany.optimalpurchasing）
一个例子
