DDD是什么？怎么使用？

前言

随着业务的不断拓展，一个项目再也不是只需要运行一段时间就可以了，也不是一个很小的项目，随着业务的增长，最终开发的代码会变成一个很大的项目，此时如果不能做好很好的重构，会造成越来越难的拓展，最后导致无法拓展。所以DDD（Domain Driven Design，领域驱动设计）就是从领域业务这个方面对代码做重构与设计的方法论之一。

另外不可能将DDD用于任何一处代码，原因如下：

0. 成本不允许，一般只有项目的核心领域才会考虑使用DDD重构，培养DDD团队会消耗比较长的时间，且整个时间成本是需要持续投入的。
1. 因为DDD无法使用于任何一个环境，只使用DDD无法做到满足全部的业务场景，比如G端企业做数据化，很多时候是只需要从数仓查询数据；但是DDD只是一个业务思想，单纯的数据也无法做到成为业务领域
2. DDD要求可以将业务分的很清晰，需要一个“聚合根”将一组业务模型组起来，这要求需要一组业务专家作为开发主力，这通常意味着需要将团队中比较聪明的几位来将项目解构成DDD的模型，很多时候这群人的工作重点不在这里。
3. 就算使用DDD也不可能将其全部的教条应用在代码中，因为工作主要是为了盈利，如果使用DDD会帮助提升代码价值，全使用DDD会降低代码价值。在这种情况下，必然是只会使用一部分的DDD思想。

Model-Driven Design

好的模型可以反应真实的业务情况

0. 好的模型需要统一的语言，在一个开发团队中，需要让每个开发者对同一个术语的概念是了解一致的，且需要业务专家将对应信息传达下去。

   如“数据资产”，数据专家和一个应届生想到的肯定是不一样的。

1. 模型类与其他非DDD层的POJO需要分离开来，尤其需要和数据库的POJO分离开来，DDD是软件设计思想，与数据库、技术组件、远程调用是完全不相关的。

2. 除了核心组件外，其他组件，如MVC的DAO层，因为其确实是需要做到和固定数据库做好对接，所以面向结果编程是完全值得提倡的。

3. DDD中一组很重要的思想是Entity和Value Object，Entity可以被认为是数据库中一张表的自增主键，具有连续性和唯一性，Value Object相当于是一个更关注其数据属性的一个组件，因此只能依附于一个Entity

4. Entity和Value Object只是提供了一组事物信息，如广告转化率、广告使用地区等。但是另外还需要非“事物”的部分引入到模型中，如行为，如一组模型相关的业务，如广告投放业务中，如果需要对广告相关的信息做校验，其中就包括业务校验和技