技术问答集录（八）（DDD）

问题：

如何理解DDD，以及DDD与微服务的关系？

 

DDD

所谓的DDD是一套软件设计方法，在国外已经有很多很多年了，老外有一点是值得我们国人学习的，就是一些人就专注一个领域，将一个领域吃的特别的透，特别的深，一干就是几十年，然后这些人就成为了这个领域的世界顶尖的大牛，DDD就是这样的，是一些专注于软件设计领域专家，立志于就在某个领域深挖，一干几十年，最终沉淀出来类似于DDD这样的很牛的一套业务软件设计的一整套理论和体系，可以去指导全世界，这些DDD专家不玩儿互联网高并发，redis内核，mongodb内核，高并发秒杀系统架构，人家未必懂的比你们多，人家就是专门搞软件设计，一搞就是30年

 

为啥最近几年DDD在国内就火了呢？

DDD在国外已经是很成熟了的，因为在软件行业，国外至少比国内多了几十年的发展时间，这几十年的时间，涌现了大量的专家，在各个细分领域里一干就是20年~30年的大叔，四五十岁的大叔，这帮人提炼出了各个细分领域里的很多理论体系和概念，极大的给软件、互联网这些行业的系统设计，树立了一个标准。而国内的软件行业，大致也就20年的时间，90年代的软件很匮乏的，也是很少的，硬是算上，也可以，80年代也有一点点软件设计和开发，互联网真正作为一个大的行业有大的发展，也就10年的时间，2010年之后，在移动互联网涌现之后。国内最近一两年到了一个阶段，就是很多公司都在做复杂的业务系统，像controller、service、dao、数据库表，这种围绕数据库进行系统设计和开发的系统，代码呈现出来跟真实世界里的系统的组件的关系和逻辑交互完全不一样，很多公司其实都在想办法改进这个现状，DDD软件设计的理论体系，就可以用武之地了

 

DDD是不是非用不可呢？

如果你的系统不是特别的复杂，可能你的技术团队总共就20人以内，小团队，做小系统，拆分成10个左右的服务，业务逻辑也没那么的复杂，此时用数据库为核心的软件设计方法+三层架构，先设计数据库表结构、然后上controller、service、dao、sql，这种以数据库为核心的软件设计的过程，他最大的好处在于速度快。而如果要用DDD，首先项目leader自己是需要精通DDD的，而且团队内的每个人都需要对DDD有一定的理解，还需要花时间整理一套界限上下文的通用语言，这个成本就比较高了，所以一般的项目就不要上DDD了，只有公司非常核心的，十分重要的项目才需要上DDD

 

如何在项目里面使用DDD呢

DDD这套东西，如果要推行和落地，起码应该是大厂P8~P9的人，对自己带的二三十人到100人不等的一个团队去整体的进行推广和落地，DDD这个东西，顶层业务建模和设计，应该是P8/P9去做的。做DDD的时候，大致有三种角色，第一种是你很牛，是大厂的P8，P9，或者是小公司的高级架构师，一个人带50~100人以上规模的团队，此时你负责的通常是公司的一个业务线，那你必须承担起DDD的责任来，做高层设计，此时就需要运用DDD去拆分子域，标记核心域、支撑子域和通用子域，每个子域可能都是一个几个人或者10人+的团队去负责，有的是10多个人的团队可能负责维护多个子域，然后此时每个团队负责一个或者多个系统，也就是多个子域，那个团队的负责人假设是个P7之类的人物，那么此时他就需要在自己的子域里继续进行DDD建模和拆分，想办法把自己负责的一个系统可能拆分为多个子系统，或者多个服务，然后每个子系统或者服务交给一两个人去负责维护

 

 

DDD与微服务的关系

其实没有大的必然联系，微服务是具体的实现方式，没有DDD也能玩微服务，有一个微服务框架，比如spring cloud,dubbo什么的，然后根据自己的业务，拆分几个子系统，然后这几个子系统分别在不同的代码仓库，子系统与子系统之间通过rpc方式进行通信，这就是微服务了。只是这种微服务就比较粗糙，服务是拆分了，但是每个服务内部还是三层架构，面向数据库来开发的，未来很可能出现新人难以理解现有代码，系统并没有一个清晰的业务模型的现象，导致系统难以维护和扩展，因为这种面向数据库来开发的软件完全不是按照真实的世界以及业务流程来设计的，模型也不是真实的，里面的各个类的交互，都不是按照真实的世界在进行交互，而是执行大量的crud。而DDD强调领域模型，有对复杂系统进行分解的具体方法论，能够指导微服务设计，也就是有了DDD，可能让你的微服务架构设计得更好​