一、软件发展的必然规律

1、软件是对真是世界的模拟，但真实世界软件十分复杂。
2、人在认识真实世界的时候总是有一个从简单到复杂的过程
3、软件需求的变更成为一种必然的事情，并且总是由简单向复杂转变
4、初期软件的业务逻辑十分简单清晰命令，慢慢变得越来越复杂

二、复杂软件和简单软件

1、简单软件设计的时候有简单的方法，复杂的有复杂的方法（设计模式）
2、但是当刚开始是简单软件，需求变更的时候，我在原来简单设计的方法里塞代码，而不是演进到复杂软件的类设计，那么就会腐化。

三、高质量代码和软件退化

1、需求变更---->扩展，解耦---->实现需求—>高质量代码
2、需求变更----->没有调整------>实现需求----->软件退化

四、两顶帽子的设计方法

1、在不添加新代码的前提下，重构代码，以适应新功能
2、实现新功能
例子：假如 A 使用的时候 需要调用B ，B需要调用C，C需要调用D。那么A使用的成本会很高，耦合性很强。
A---->B----->C----->D
我们希望在应用A的时候不要强依赖：B，C，D解耦
抽取出一个B的接口B’，那么变更就会变得容易了。
A—B‘–>B---->C----->D
把需要变更地方的抽取成接口，然后第一个实现是过去的实现，新的实现是为了新的需求而做的实现，以此来应对变更。这个接口叫做可扩展点。

3、难点：是在第一点，重构。第一次第二次可能还能想清楚变更说明，如果迭代了十几轮，就很难想清楚了，就不知道怎样变得设计质量更高，维护成本更低了。所以需要一个变更的的指导方法。

五、领域模型及建模思想

1、领域驱动思想的本质：

软件的本质是对真是世界的模拟，把软件设计和真实世界对应起来，真实世界是什么样子的，软件就是什么样子的。当遇到新的需求变更的时候，我们先把新的需求放在真实世界里。无论找到多少轮的变更，我们都能找到设计。

2、如何将软件世界和真实世界对应起来？

①现实世界有什么事物—>软件世界就有什么对象
②现实世界这些对象有什么行为—>软件世界这些对象就有什么方法
③现实世界这些对象是什么关系—>软件设计这些对象就有什么关联
把这三个对应关系，制作成一个领域模型，再由这个领域模型，指导我们的开发。当我们遇到需求变更，先回到领域模型，领域模型对应的是真实世界，真实世界是什么样子的，通过真实世界先修改领域模型，然后通过领域模型指导程序的修改。

3、在领域模型里绘制的都是业务，业务和技术严格区分，不包含技术的事情。

当落实到设计开发的时候再考虑技术。因为技术是在一致变化的，但是业务是不变的，一个业务可以由不同的技术实现。当我们修改的时候，修改的是领域模型里的业务，当我们的系统越来越复杂的时候， 我们复杂的系统就是对现实世界抽象出来的业务。那么再业务上的变更会更加清晰。

4、案例：下单付款场景：

领域驱动设计过程：领域建模过程—>领域模型指导数据库设计---->领域模型指导软件设计

①原始需求：

用户付款功能：
Ⅰ、用户下单以后，经过下单流程进入付款功能
Ⅱ、通过用户档案获取用户名称，地址等信息
Ⅲ、记录商品及数量，并汇总付款金额。
Ⅳ、保存订单
Ⅴ、通过远程调用支付接口，进入支付功能。

②第一个版本的领域模型

③第一个版本的程序设计

④增加商品折扣功能

Ⅰ、限时折扣
Ⅱ、限量折扣
Ⅲ、对某类商品进行折扣
Ⅳ、对某个商品进行折扣
Ⅴ、不折扣

⑤坏味道：直接写代码

⑥再第一个版本的领域模型去分析

⑦思路：SRP，单一职责原则：一个职责是软件变化的一个原因。

⑧如何分析付款和折扣两者的关系

付款发生变化的时候，折扣一不一定变化。折扣变化的是，付款一不一定变化。
如果为否，那么付款和折扣就是软件变化的两个不同原因，因此把折扣写入付款就不合适了。
同理，限时折扣发生变化的时候，限量折扣一定变化么，某个商品折扣，某个商品折扣，不折扣一定发生变化么。我们发现不同类型的折扣也是软件变化的两种不同原因，所以，写在一个类里也不合适。

⑨第二个版本的领域模型设计

那么以后付款发生变更，和折扣变更没有干系，折扣变化也和付款变化没有关系。

⑩第二个版本的设计实现

领域驱动设计真正发挥优势：日后的维护，需求不同提取，系统在不断的变更，如何在新系统变更中维护系统。
新项目使用领域驱动设计，为了在日后的维护过程中，进行正确的设计，帮助我们维护。第一次开发并不一定能有用