DDD领域驱动开发

1. 现象:

       软件设计质量最高的时候是第一次设计的那个版本（通常是因为第一次设计时，业务技术沟通最充分，从业务技术整体视角出发设计系统）。当第一个版本设计上线以后就开始各种需求变更，这常常又会打乱原有的设计。

2. 原因：

        软件的本质就是对真实世界的模拟。软件中业务逻辑正确与否的唯一标准就是是否与真实世界 一致。

      软件要做成什么样，既不由我们来决定，也不由用户来决定，而是由客观世界决定。

3.项目代码发展过程（0到1）：

     最初只能认识真实世界中那些简单、清晰、易于理解的业务逻辑，把它们做到我们的软件里，还有很多不简单、不明了、不易于理解的业务逻辑没做到软件里。（项目刚上线时，先写最主要和常见的场景逻辑）

    后续变化：软件的业务逻辑会越来越接近真实世界，使得我们的软件越来越专业，同时业务逻辑就会变得越来越复杂，软件规模也越来越庞大。（项目上线后，可能增加多渠道，多场景的使用，要兼容复杂/少见/异常等场景）

小结：软件退化的根源不是软件变更，软件变更只是一个诱因。

4.如何解决：

要保持软件设计质量不退化，必须在每次需求变更的时候，对原有的程序结构适当地进行调整。

5.关键：

每次需求变更的设计，只有保证每次需求变更时做出正确的设计（由于时间赶工期/人员素质参差不齐，不熟悉原有系统的情况/资源限制等，通常很难完美实现），才能保证软件以一种良性循环的方式不断维护下去

6.常有的事：经历了多次变更，这些事情就想不清楚了，设计开始迷失方向

7.设计的原则

理想的逻辑：

总结：
软件发展的规律就是逐步由简单软件向复杂软件转变
DDD给了我们的思路: 
在每次变更的时候，先回到领域模型，基于业务进行领域模型的变更