白话浅析DDD

序言：IT的世界，各种名词、缩写、概念，炫酷而又玄奥莫测，偏偏还多如繁星。要弄明白这些东西需要勇气，我们只能一个一个来。本文以简单直白的语言描述DDD（领域驱动设计）的基本概念，不求博大精深，但求通俗易懂。

 

一、DDD是干嘛的，解决什么问题？

传统的软件开发过程，从需求、分析、设计到编码，经历了多个过程，产生各种工件，最终实现可以运行的软件系统。DDD人认为，传统开发过程存在的问题主要包括：

1，输入输出一环套一环，任何一个环节出错，则基于此环节的后续环节会延续错误，难以发现、难以修正；

2，各个环节的参与人员技术背景各不相同，缺乏通用的语言描述软件系统，导致沟通过程中信息失真；

3，软件产品研发的目的是最终良好运行的代码，而过程中却投入了太多的成本产生各个环节的输出工件；

那么DDD是如何解决这些问题的？

DDD的基本过程是：领域专家和开发人员以领域通用语言作为沟通交流的基础，共同完成领域模型的建立，领域模型承载业务的同时，也基本完成了对应的设计；最后将领域模型基于架构映射为实现代码，就完成了开发。按照如此过程，整个DDD的开发过程很好的解决了传统开发过程中的问题。

二、DDD经典分层架构

        

         领域驱动设计的经典分层架构如上图，基本的分层架构，核心是Domain层。

 

三、Domain层包含些什么？

在DDD的基本架构模型中，Domain层封装所有业务及数据，具体domain层中包含哪些模型，各自的作用，了解了这些也就基本明白了DDD是如何实现业务。具体domain层涉及如下概念：

1，实体：业务领域中需要被唯一标识的实体对象；实体封装了所有该业务实体的所有属性和行为；

2，值对象：业务领域中不需要被唯一标识的实体对象；通常是实体模型中抽象分离出来的一部分属性，比如：地址、规格型号信息等；值对象通常具备属性但没有行为，依附于实体存在，可能影响实体的具体行为；

3，聚合（根、一致性）：在实际业务中，一组实体和值对象是高内聚的，属性在业务维度上也需要保持一致性；它们组合在一起，被当做一个整体对外提供服务，这个整体就是聚合；DDD中，不以实体对外暴露行为，对外提供服务的是聚合；

4，根：通常聚合是由1个或者2到3个实体加上几个值对象组合起来的，根是其中的一个实体，负责对外提供接口和对内维护业务规则；

5，工厂：由于聚合的存在，领域对象会比较复杂，通过工厂来隐藏聚合的创建细节，使调用方能够很容易使用聚合就是很顺理成章的事情了；

6，仓储：仓储和工厂一样，都是针对聚合的，聚合不只是对外提供接口的边界，也是持久化的一个边界，仓储负责管理聚合状态的持久化和聚合对象的重建；

7，领域服务：领域服务主要用来封装不能由单独的聚合完成的业务功能，通常是在一个业务场景中协调跨聚合的操作；

 

四、反思，存在的问题：

1，重中之重：领域通用语言；关于领域通用语言，个人觉得是DDD实践的基础，没有领域通用语言，就不能解决沟通的问题，领域专家和设计人员就无法共同完成设计；实际中大多数团队都是依赖于UML来完成建模，而实际上这毕竟是个建模的语言，对业务领域专家也是不小的门槛；

2，领域模型是充血模型；模块化了，但粒度粗； 业务实体，在实际业务中，通常参与到多个业务中去；这意味着，具体的实体和聚合的行为定义，受到多个业务的影响；而这通常说明实体和聚合的职责不单一，维护比较复杂；

3，团队成员要求高（我们把整个聚合看成是一个整体概念，要么一起被取出来，要么一起被删除。我们永远不会单独对某个聚合内的子对象进行单独查询或做更新操作。）必须通盘理解和掌握业务，否则划分不出合适的高复用的聚合；实际使用中，70%的聚合是单实体的，不是因为70%的实体间没有关联，而是因为要划分出合适粒度的聚合太难。

 

五、总结：

         DDD是一种比较切实可行的敏捷方法论，在很多中大型的软件产品中取得了成功，但也对产品研发团队提出了更高的要求。如何使用或借鉴DDD，需要软件团队根据自身的情况慎重考虑。