大白话DDD（DDD黑话终结者）

一、吐槽的话

相信听过DDD的人有很大一部分都不知道这玩意具体是干嘛的，甚至觉得它有那么一些虚无缥缈。原因之一是但凡讲DDD的，都是一堆特别高大上的概念，然后冠之以一堆让人看不懂的解释，。作者曾经在极客时间上买了本DDD实战的电子书，被那些概念一路从头灌到尾，灌得作者头昏脑涨，一本电子书那么多文章愣是没有一点点像样的案例，看到最后也 没明白那本电子书的作者究竟想写啥。原因之二是DDD经常出现在互联网黑话中，如果不能稍微了解一下DDD中的名词，我们一般的程序员甚至都不配和那些说这些黑话的人一起共事。

为了帮助大家更好的理解这种虚无缥缈的概念，也为了更好的减少大家在新词频出的IT行业工作的痛苦，作者尝试用人话来解释下DDD，并且最后会举DDD在不同层面上使用的例子，来帮助大家彻底理解这个所谓的“高大上”的概念。

二、核心概念

核心的概念还是必须列的，否则你都不知道DDD的名词有多么恶心，但我会用让你能听懂的话来解释。

1、领域/子域/核心域/支撑域/通用域

领域

DDD中最重要的一个概念，也是黑话中说的最多的，领域指的是特定的业务问题领域，是专门用来确定业务的边界。

子域

有时候一个业务领域可能比较复杂，因此会被分为多个子域，子域分为了如下几种:

• 
  
• 核心子域：业务成功的核心竞争力。用人话来说，就是领域中最重要的子域，如果没有它其他的都不成立，比如用户服务这个领域中的用户子域
  
• 通用子域：不是核心，但被整个业务系统所使用。在领域这个层面中，这里指的是通用能力，比如通用工具，通用的数据字典、枚举这类（感叹DDD简直恨不得无孔不入）。在整个业务系统这个更高层面上，也会有通用域的存在，指的通用的服务（用户服务、权限服务这类公共服务可以作为通用域）。
  
• 支撑子域：不是核心，不被整个系统使用，完成业务的必要能力。
  

2、通用语言/限界上下文

通用语言

指的是一个领域内，同一个名词必须是同一个意思，即统一交流的术语。比如我们在搞用户中心的时候，用户统一指的就是系统用户，而不能用其他名词来表达，目的是提高沟通的效率以及增加设计的可读性

限界上下文

限界上下文指的是领域的边界，通常来说，在比较高的业务层面上，一个限界上下文之内即一个领域。这里用一张不太好看的图来解释：

3、事件风暴/头脑风暴/领域事件

事件风暴

指的是领域内的业务事件，比如用户中心中，新增用户，授权，用户修改密码等业务事件。

头脑风暴

用最俗的人话解释，就是一堆人坐在一个小会议室中开会，去梳理业务系统都有哪些业务事件。

领域事件

领域内，子域和子域之间交互的事件，如用户服务中用户和角色交互是为用户分配角色，或者是为角色批量绑定用户，这里的领域事件有两个，一个是“为用户分配角色”,另一个是“为角色批量绑定用户”。

4、实体/值对象

实体

这里可以理解为有着唯一标识符的东西，比如用户实体。

值对象

实体的具体化，比如用户实体中的张三和李四。

实体和值对象可以简单的理解成java中类和对象，只不过这里通常需要对应数据实体。

5、聚合/聚合根

聚合

实体和实体之间需要共同协作来让业务运转，比如我们的授权就是给用户分配一个角色，这里涉及到了用户和角色两个实体，这个聚合即是用户和角色的关系。

聚合根

聚合根是聚合的管理者，即一个聚合中必定是有个聚合根的，通常它也是对外的接口。比如说，在给用户分配角色这个事件中涉及两个实体分别是用户和角色，这时候用户就是聚合根。而当这个业务变成给角色批量绑定用户的时候，聚合根就变成了角色。即使没有这样一个名词，我们也会有这样一个标准，让业务按照既定规则来运行，举个上文中的例子，给用户A绑定角色1，用户为聚合根，这样往后去查看用户拥有的角色，也是以用户的唯一标识来查，即访问聚合必须通过聚合根来访问，这个也就是聚合根的作用。

三、用途及案例

目前DDD的应用主要是在战略阶段和战术阶段，这两个名词也是非常的不讲人话，所谓的战略阶段，其实就是前期去规划业务如何拆分服务，服务之间如何交互。战术阶段，就是工程上的应用，用工程化做的比较好的java语言举例子，就是把传统的三层架构变成了四层架构甚至是N层架构而已。

1、微服务的服务领域划分

这是对于DDD在战略阶段做的事情：假如目前我司有个客服系统，内部的客服人员使用这个系统对外上亿的用户提供了形形色色的服务，同时内部人员觉得我们的客服系统也非常好用，老板觉得我们的系统做的非常好，可以拿出去对外售卖以提高公司的利润，那么这时候问题就来了，客服系统需要怎样去改造，才能够支持对外售卖呢？经过激烈的讨论，大致需求如下：

• 
  
• 对外售卖的形式有两种，分别是SaaS模式和私有化部署的模式。
  
• SaaS模式需要新开发较为复杂的基础设施来支持，比如租户管理，用户管理，基于用户购买的权限系统，能够根据购买情况来给予不同租户不同的权限。而私有化的时候，由于客户是打包购买，这时候权限系统就不需要再根据用户购买来判断。
  
• 数据同步能力，很多公司原本已经有一套员工管理系统，通常是HR系统或者是ERP，这时候客服系统也有一套员工管理，需要把公司人员一个一个录入进去，非常麻烦，因此需要和公司原有的数据来进行同步。
  
• 老板的野心还比较大，希望造出来的这套基础设施可以为公司其他业务系统赋能，能支持其他业务系统对外售卖
  

在经过比较细致的梳理（DDD管这个叫事件风暴/头脑风暴）之后，我们整理出了主要的业务事件，大致如下：

1、用户可以自行注册租户，也可以由运营在后台为用户开通租户，每个租户内默认有一个超级管理员，租户开通之后默认有系统一个月的试用期，试用期超级管理员即可在管理端进行用户管理，添加子用户，分配一些基本权限，同时子用户可以使用系统的一些基本功能。

2、高级的功能，比如客服中的机器人功能是属于要花钱买的，试用期不具备此权限，用户必须出钱购买。每次购买之后会生成购买订单，订单对应的商品即为高级功能包。

3、权限系统需要能够根据租户购买的功能以及用户拥有的角色来鉴权，如果是私有化，由于客户此时购买的是完整系统，所以此时权限系统仅仅根据用户角色来鉴权即可。

4、基础设施还需要对其他业务系统赋能。

根据上面的业务流程，我们梳理出了下图中的实体

最后再根据实体和实体之间的交互，划分出了用户中心服务以及计费服务，这两个服务是两个通用能力服务，然后又划分出了基于通用服务的业务层，分别是租户管理端和运营后台以及提供给业务接入的应用中心，架构图如下：

基础设施层即为我们要做的东西，为业务应用层提供通用的用户权限能力、以及售卖的能力，同时构建开发者中心、租户控制台以及运营后台三个基础设施应用。

2、工程层面

这个是对于DDD在战术设计阶段的运用，以java项目来举例子，现在的搞微服务的，都是把工程分为了主要的三层，即控制层->逻辑层->数据层，但是到了DDD这里，则是多了一层，变成了控制层->逻辑层->领域能力层->数据层。这里一层一层来解释下：

四、总结

在解释完了各种概念以及举例子之后，我们对DDD是什么有了个大概的认知，相信也是有非常多的争议。作者搞微服务已经搞了多年，也曾经在梳理业务的时候被DDD的各种黑话毒打过，也使用过DDD搞过工程。经历了这么多这方面的实践之后觉得DDD最大的价值其实还是在梳理业务的时候划分清楚业务领域的边界，其核心思想其实还是高内聚低耦合而已。至于工程方面，现在微服务的粒度已经足够细，完全没必要再多这么一层。这多出来的这一层，多少有种没事找事的感觉。更可笑的是，这个概念本身在对外普及自己的东西的时候，玩足了文字游戏，让大家学的一头雾水。真正好的东西，是能够解决问题，并且能够很容易的让人学明白，而不是一昧的造新词去迷惑人，也希望以后互联网行业多一些实干，少说一些黑话。