DDD专题系列(一)---为什么要用DDD

一、为什么使用DDD

​ 首先，按照常规套路，解释一下DDD. DDD的英文全称是Domain Driven Design(领域驱动设计) ,多的我就不讲了，大家应该都知道。关于DDD,业界一直争论很大, 很多人对于DDD的都有着不同的理解，一部分人支持者大力鼓吹DDD的优点，另一部分人则认为DDD被吹捧的过头了。这里先表达一下我个人观点: DDD本来分为了战略设计和战术设计两部分, 很大一部分人只看到了战术设计这一部分，如果单单从战术设计这个角度去对比，那就变成了组织代码的一种形式而已，和其他的符合了高内聚, 低耦合思想的代码没什么优势所在；但真正能体现DDD巨大优势与潜力的是战略设计部分，它更像是大型团队开发的一种指导方针，下面我将从几个部分讲讲。

1. 成本问题

   ​ 从成本的角度去看DDD，先摆一张很经典的图，其实一本DDD的经典书籍就把这张图放了出来，当然我这有些地方画的幅度有点大，但是大致趋势都能看出来。横坐标表示系统的复杂度，复杂度这个大家应该都清楚，随着时间的累积，功能越迭越多; 纵坐标是时间和人力成本。我觉得这副图能够解释很多现象:

a. 目前主流的开发架构还是三层

​ 形成这种局面的主要原因是: 前期或者起步阶段(传统互联网转型或者初创型公司)，三层对于他们而言是最优的方案(因为公司得考虑活下来的问题),但是这个泥球一开始肯定能够承受住，感觉非常香，可是随着业务的增长，越滚越大, 绝大部分公司都有这种"大泥球"的旧系统。它能够正常运转，而且还能时不时加些小需求，性能也还不错，这时候公司层面很难再去花费如此大的成本去冒险的去重构这个系统，又不是不能用。

​ b. 大部分公司没有发挥出DDD的真正优势

​ 一部分公司的人说: 我们目前使用的就是DDD的架构模式，但是仅仅是战术层面上使用了DDD中的某些理念。达到相对好的状态是，团队分工协作，人员分配合理，职责明确，各个团队之间的沟通交流紧密且默契配合，当然这是一种非常理想的状态，可是也不乏为我们指明了一个风向标。

2. 自身的局限性

   ​ 任何事物都不是完美的! DDD也不是任何场景下适合，如果我们要最大限度发挥它的作用，得考虑当前资源条件，社会背景等诸多因素。

a) DDD只适用于有足够高的复杂度的系统, 如果过于简单的系统反而会让你感觉越写越复杂。(杀鸡焉用宰牛刀)在后面的文章中我会让大家详细体会到。

b) 适用于大型企业级应用的开发。这里大家千万不要把QQ、微信、Facebook这一类应用包含在里面，这些应用都是逐渐演化出来的，不同的应用关注点不一样，对于某些应用的性能或者某方面提出了极其苛刻的要求，这时候就不适合采用DDD了。

3. 总结

   ​ DDD是一个需要成本的开发架构，对于开发人员以及整个团队都提出了相对较高的要求，关于他的战略设计和战术设计方面。我们可以这样理解，战术设计相当于指导我们如何赢得一场战斗，战略设计相当于知道我们如何赢得一场战役。一场战役可能由许多场战斗组成，大部分时候我们所希望的赢得整场战役的胜利。

   下面我也将从战略设计和战术设计两个方面做分别讲述。