DDD领域驱动设计简介

1、起源及阶段

     2003年由Eric Evans完成了《Domain-Driver Design Tacking Complexity in the Heart of Software》一书开始，DDD进入大众视野。

    主要3个阶段：1、Eric Evans的理论原则创建和普及阶段；

                            2、引入领域事件、事件溯源阶段；

                            3、微服务架构提出阶段。

 2、何为DDD？

       DDD将分析和设计结合起来，通过上下文的特殊性，将项目的真正业务背景和继承复杂性引入设计建模阶段，虽然增加了设计复杂性，但也提高了设计的实用性。

       DDD分析方法核心：从细节动词入手发现有界上下文和聚合，以逻辑一致性为边界划分依据，对动作实现分门别类的画法。

3、为什么会有DDD需求？为什么DDD逐渐风生水起？    

       其根本原因需要放在一个更大的上下文（或背景）中去寻找，这个上下文就是软件质量。

       技术负债： 按照Martin Fowler的定义就是增加新功能所需的额外成本。技术负债是导致软件质量下降的重要原因。

       降低技术负债的解决办法一种是适度问题，即适度的单一设计原则和DRY（不要重复自己）原则。另一种是引入架构元素，将各个环节串通，例如编码完后增加单元测试和集成测试，尽可能将测试、发布和运维自动化实现DevOps哲学化管理。

       ER数据建模虽然也有一套分析设计方法论，但是由于过于注重数据库技术而忽视了业务上下文。例如创建订单替代“下单”。通过CRUD通用词替代业务术语，最大的遗憾就是丢失业务上下文以后，设计的逻辑性将很难去追溯和质疑。

        面向对象分析和设计：基于对象，直接面对的是对象而不是数据表、不是ER数据模型。

        业务领域中业务对象是定义业务行为的一种结构；数据表模式是定义业务数据的结构。他们一个重业务行为，另一个重视业务的数据。不同的设计要求才有对象和数据结构两种不同实现方式。跟跟那个精确放映领域概念，保证业务规则真正逻辑一致地实现，是面向对象分析和设计（OOAD）的主要有点。但是，传统面向对象分析和设计也有问题，如分析和设计之间落差很大，甚至分裂。正是这一背景下，人们期待一中心的分析设计方法问世，它应比ER数据建模更加面向业务，能够弥补OOA和OOD之间的天然裂缝，于是DDD来了。

4、DDD应用场景

      不适合应用DDD的场景： 

       1、传统的CRUD系统不适合使用DDD。因为大部分是简单系统

        2、小型系统或教学案例系统也不适合使用DDD。通常都是具体技术的使用和业务无关。

        3、业务问题基本转化为数据表结构来实现的也就是通过纯数据结构完成，这样的系统如果再使用DDD重构比较难，业务规则、模型核心都体现在数据表结构中，即使这些表结构设计不合理，考虑大量历史遗留数据，也很难进行范式转换。

        4、如果是第一版系统1.0版时间紧任务重只是让软件运行起来，摸索的初步影响和结果，可以在后期需求方向渐渐确定后再迭代版本时将DDD应用上。

      适合场景：

             SOA服务和微服务架构的软件。