领域驱动设计——精简版

一、理解领域

1. 一个软件的起点：领域
2. 软件的最终目的：增进一个特殊的领域
3. 软件需要对领域进行建模
4. 模型是对领域的抽象
5. 领域和程序需要用模型来交流（两个专业领域的交汇：软件专家和领域专家）
   tips：

瀑布设计方法：
业务专家提出需求 —————> 业务分析人员根据需求创建模型 ————> 开发人员编码
问题：各个层级的反馈不及时，开发完成后业务专家再来提出整改，甚至推到重做
敏捷开发：
因为难以做出一个完整的全面的设计，所以敏捷开发提倡只考虑当前，不做预先设计，通过迭代和重构来学习领域知识
问题：缺乏真实可见的设计原则，持续重构很难

二、通用语言

1. 软件专家和领域专家开发出一个领域模型是绝对需要的，创建这个模型遇到的第一个困难是交流障碍，这是需要一个大家都能理解的通用语言
2. 使用一种基于模型的语言
3. 需要取发现和定义领域和模型的关键性概念，发现描述他们的相应的用词
4. 代码的类、方法命名应该与新模型适应
5. 不要试图去做一个反映整体模型的大图，应该做一个个整体模型的子集，每个子集有子集的描述

三、模型驱动设计

1. 软件开发，应该以业务领域为中心
2. 让模型根植于领域，并让领域反应出模型中的基础概念
3. 模型的建立应该由领域专家和软件分析人员讨论，并让开发人员全程参与，这样形成从开发人员到分析人员到领域专家的语言一致性，到模型一致性，到代码与模型的统一
4. 模型达到一定规模时候，需要给模型划分模块，划分模型的模块时，模块的名称也应该是通用语言的一部分
5. 领域对象的设计：当一个对象不足以完全表达一个领域对象时，将其中部分属性抽成该领域对象的一个子对象，进行统一管理，该领域对象为根对象，一个根对象可能对应多个子对象

四、面向深层理解的重构

五、保持模型一致性

1. 大型项目，每个团队会被指定模型的一部分模块进行开发，每个团队开发的接口提供给其他团队使用，此时每个团队对自己的模块很了解，但是对整个模型可能不太了解，会导致模型不一致
2. 理想情况下，企业应该有一个大的统一的涵盖所有领域的没有重叠的完整的模型，但是维护一个大的统一的模型是难以实现的，好的做法是将大的模型分解成小的模型，每个模型都要遵守互相绑定的契约，且又相互独立
3. 模型的划分，应该把相关联的能形成一个自然概念的因素放在一个模型里，且模型应该足够小，以便能交给一个团队去实现
4. 模型划分时，要定义好模型的范围和上下文边界
5. 企业内部有一个大的模型，大的模型被拆分成很多小的模型，每个模型有自己的边界和上下文，最好让所有人都了解所有的模型，这样在模型之间的交互才会畅通
6. 上下文映射模式：

• 共享内核模式：（在一套代码里开发）需要注意对内核代码（共享代码）的修改两个团队之间应该密切沟通
• 客户-供应商模式：两个团队独立开发，客户和供应商提前商量好交互的接口，客户调用供应商的接口，此时需要良好的管理，来约束供应商对客户提供良好的服务
• 顺从者模式：如果供应商没有精力或者不愿意提供服务，这时可以考虑成为供应商的顺从者，使用供应商的模型（内核），不需要供应商主动提供接口

7. 对于新模型与老模型或者老应用交互，需要增加防崩溃层，使用设计模式（门面模式，适配器模式）来分离新模型和老应用的交互
8. 我们可以通过共享模式，客户-供应商模式，顺从者模式来整合各个子系统，使他们协同工作，我们在开发自己的项目的时候，还必须兼顾其他团队的需求，这是有可能在做出某些妥协，甚至是修改模型，如果一个应用可以划分成独立的模型，且通过评估，不会存在模型走向集成化系统的情况，可以考虑独立方法模式
9. 独立方法模式：从用户角度上看是一个应用，在模型上可以拆分成多个独立的模型，创建独立的界定和上下文，最后通过共用GUI来组织成一个应用
10. 开放主机服务：对于其他系统需要集成你的系统提供服务时，不要尝试去接入他们的系统来提供服务，而要按照某种协议，对外提供服务，这样你就不用为每个接入的系统提供转换层，并维护各个系统，你只需要根据以后的特殊需求，提供新的服务即可
11. 精炼：领域模型需要仔细讨论，多次重构，逐步理清楚领域的核心模型，并抽离出一个精简的领域核心，其他的部分抽取成普通子领域，一起形成一个完整的模型