本文来说下DDD，第一次认识DDD。后面会多写几篇文章来深入理解下什么是DDD。

文章目录

概述
什么是DDD
啥是驱动
建立领域知识(Build Domain Model)
通用语言(Ubiquitous Language)
模型关系图(Model-Driven Design)
层结构(Layered Architecture)
实体(Entity) & 值对象(Value Object)
服务(Services)
模块(Moudles)
聚合(Aggregates)
工厂(Factories)
仓库(Repository)
本文小结

概述

最近在做一些微服务相关的设计，内容包括服务的划分，Restful API的设计等。其中比较棘手的就是Service的职责划分：如何抽象具有统一业务范畴的Model，使其模块化，又如何高度提炼并组合多模块，使得业务可独立服务化。为了找寻答案，看了不少书籍和博客，在DDD中找到了一些思路，个人觉得受益匪浅，或许也可以受用于大家，特分享于此。

打开 DDD 相关的书籍，你会被一系列生硬、高深的概念充斥，拜读完毕，满头雾水。这不是你的问题，而是 DDD 本身的问题，表现形式太概念化。学习它的内核，就不要被它给出的概念所迷惑，而要去思索这些概念背后所蕴含的设计原则，多问一些为什么，本质无外乎是 SOLID。最重要的，要学会运用设计原则去解决问题，而非所谓的 “设计规范”。

本文将会以系列解答的方式展开，由浅入深，篇幅不长，无妨一看。

什么是DDD

DDD本质上是一种方法论，提供了一套系统开发的设计方法。面对需要解决的问题，从复杂的现实中抽象出业务模型的思维方式与实践技巧。初衷是清晰设计思路，规范设计过程。

软件开发不是一蹴而就的事情，我们不可能在不了解产品（或行业领域）的前提下进行软件开发，在开发前，通常需要进行大量的业务知识梳理，而后到达软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念。

听起来这和传统意义的软件开发没啥区别，只是换了点新鲜的名词而已，其实不然。

啥是驱动

DDD 强调是说得先把 “领域” 中涉及到的数据、流程、规则等都弄明白了，然后以面向对象的观点为其建立一个模型（即领域模型），而这个模型，决定了你将用什么技术、什么架构、什么平台来实现这个系统。所以技术在这个过程中是 “被动的”，是被 “选来” 实现 “领域模型” 的。对于项目的成败，技术不是决定性因素，领域模型是否符合事物的本质才是关键。

可以看出，领域驱动设计的出发点是业务导向，技术服务于业务。

建立领域知识(Build Domain Model)

说了这么多领域模型的概念，到底什么是领域模型呢？以飞机航行为例子：

现要为航空公司开发一款能够为飞机提供导航，保证无路线冲突监控软件。那我们应该从哪里开始下手呢？根据DDD的思路，我们第一步是建立领域知识：作为平时管理和维护机场飞行秩序的工作人员来说，他们自然就是这个领域的专家，我们第一个目标就是与他们沟通，也许我们并不能从中获取所有想要的知识，但至少可以筛选出主要的内容和元素。你可能会听到诸如起飞，着陆，飞行冲突，延误等领域名词，让们从一个简单的例子开始（就算是错误的也没关系）：

起点－>飞机－>终点

这个模型很直接，但有点过于简单，因为我们无法看出飞机在空中做了什么，也无法得知飞机怎么从起点到的终点，刚才我们似乎提到无路线冲突，那么如此似乎会好些：

飞机－>路线－>起点/终点

既然点构成线，那何不：

飞机－>路线－>points（含起点，终点）

这个过程，是我们不断建立领域知识的过程，其中的重点就是寻找领域专家频繁沟通，从中提炼必要领域元素。

尽管看起来还是很简单，但我们已经开始一步步的在建立领域对象和领域模型了。

通用语言(Ubiquitous Language)

上面的例子的确看起来简单，但过程并非容易：我们（开发人员）和领域专家在沟通的过程中是存在天然屏障的：我们满脑子都是类，方法，设计模式，算法，继承，封装，多态，如何面向对象等等；这些领域专家是不懂的，他们只知道飞机故障，经纬度，航班路线等专业术语。

所以，在建立领域知识的时候，我们（开发人员和领域专家）必须要交换知识，知识的范围范围涉及领域模型的各个元素，如果一方对模型的描述令对方感到困惑，那么应该立刻换一种描述方式，直到双方都能够接受并且理解为止。在这一过程中，就需要建立一种通用语言，作为开发人员和领域专家的沟通桥梁。

可如何形成这种通用语言呢？其实答案并不唯一，确切的说也没有什么标准答案。

a)UML

利用UML可以清晰的表现类，并且展示它们之间的关系。但是一旦聚合关系复杂，UML叶子节点将会变的十分庞大，可能就没有那么直观易懂了。最重要的是，它无法精确的描述类的行为。为了弥补这种缺陷，可以为具体的行为部分补充必要说明（可以是标签或者文档），但这往往又很耗时，而且更新维护起来十分不便。

b)伪代码

极限编程是推荐这么做的，这个办法对程序猿来说固然好，可立刻就要将现有模型映射到代码层面，这对人的要求也是不低，并不容易实现。

模型关系图(Model-Driven Design)

领域驱动设计中的模型关系图如下：

层结构(Layered Architecture)

User Interface

负责向用户展现信息，并且会解析用户行为，即常说的展现层。

Application Layer

应用层没有任何的业务逻辑代码，它很简单，它主要为程序提供任务处理。

Domain Layer

这一层包含有关领域的信息，是业务的核心，领域模型的状态都直接或间接（持久化至数据库）存储在这一层。

Infrastructure Layer

为其他层提供底层依赖操作。

层结构的划分是很有必要的，只有清晰的结构，那么最终的领域设计才宜用，比如用户要预定航班，向Application Layer的service发起请求，而后Domain Layler从Infrastructure Layer获取领域对象，校验通过后会更新用户状态，最后再次通过Infratructure Layer持久化到数据库中。

实体(Entity) & 值对象(Value Object)

实体(Entity)

实体与面向对象中的概念类似，在这里再次提出是因为它是领域模型的基本元素。在领域模型中，实体应该具有唯一的标识符，从设计的一开始就应该考虑实体，决定是否建立一个实体也是十分重要的。

值对象(Value Object)

值对象和我们说的编程中数值类型的变量是不同的，它仅仅是没有唯一标识符的实体，比如有两个收获地址的信息完全一样，那它就是值对象，并不是实体。值对象在领域模型中是可以被共享的，他们应该是“不可变的”（只读的），当有其他地方需要用到值对象时，可以将它的副本作为参数传递。

服务(Services)

当我们在分析某一领域时，一直在尝试如何将信息转化为领域模型，但并非所有的点我们都能用Model来涵盖。对象应当有属性，状态和行为，但有时领域中有一些行为是无法映射到具体的对象中的，我们也不能强行将其放入在某一个模型对象中，而将其单独作为一个方法又没有地方，此时就需要服务.

服务是无状态的，对象是有状态的。所谓状态，就是对象的基本属性：高矮胖瘦，年轻漂亮。服务本身也是对象，但它却没有属性（只有行为），因此说是无状态的。

PS:这与我们常说的服务器的状态是两个概念，无状态的服务器是指，对服务器来说每次接收到的HTTP请求都像是客户端第一次发送的一样；而有状态的服务器就会存储客户端的状态，常见的就是Cookie&Session

服务存在的目的就是为领域提供简单的方法。为了提供大量便捷的方法，自然要关联许多领域模型，所以说，行为(Action)天生就应该存在于服务中。

服务具有以下特点：

服务中体现的行为一定是不属于任何实体和值对象的，但它属于领域模型的范围内
服务的行为一定设计其他多个对象
服务的操作是无状态的

PS:不要随意放置服务,如果该行为是属于应用层的，那就应该放在那；如果它为领域模型服务，那它就应该存储在领域层中，要避免业务的服务直接操作数据库，最好通过DAO。

模块(Moudles)

对于一个复杂的应用来说，领域模型将会变的越来越大，以至于很难去描述和理解，更别提模型之间的关系了。模块的出现，就是为了组织统一的模型概念来达到减少复杂性的目的的。而另一个原因则是模块可以提高代码质量和可维护性，比如我们常说的高内聚，低耦合就是要提倡将相关的类内聚在一起实现模块化。

模块应当有对外的统一接口供其他模块调用，比如有三个对象在模块a中，那么模块b不应该直接操作这三个对象，而是操作暴露的接口。模块的命名也很有讲究，最好能够深层次反映领域模型。

聚合(Aggregates)

聚合被看作是多个模型单元间的组合，它定义了模型的关系和边界。每个聚合都有一个根，根是一个实体，并且是唯一可被外访问的。正是如此，聚合可以保证多个模型单元的不变性，因为其他模型都参考聚合的根。所以要想改变其他对象，只能通过聚合的根去操作。根如果没有了，那么聚合中的其他对象也将不存在。

一个简单的例子如下：

customer是该聚合的根，其他的都是内部对象，如果外部需要用户地址，拷贝一份传递出去即可。显而易见，用户如果不存在，其他信息均无意义。

工厂(Factories)

在大型系统中，实体和聚合通常是很复杂的，这就导致了很难去通过构造器来创建对象。工厂就决解了这个问题，它把创建对象的细节封装起来，巧妙的实现了依赖反转。当然对聚合也适用（当建立了聚合根时，其他对象可以自动创建）。工厂最早被大家熟知可能还是在设计模式中，的确，在这里提到的工厂也是这个概念。

但是不要盲目的去应用工厂，以下场景不需要工厂：

a)构造器很简单
b)构造对象时不依赖于其他对象的创建
c)用策略模式就可以解决

仓库(Repository)

仓库封装了获取对象的逻辑，领域对象无须和底层数据库交互，它只需要从仓库中获取对象即可。仓库可以存储对象的引用，当一个对象被创建后，它可能会被存储到仓库中，那么下次就可以从仓库取。如果用户请求的数据没在仓库中，则会从数据库里取，这就减少了底层交互的次数。当然，仓库获取对象也是有策略的，如下：

PS:仓库看起来有些像Infrastructure Layer的东西，但其实不然，仓库更像是本地缓存，需要时才会访问数据库

本文小结

CQRS本身也是一种架构模式，但更多的是它被应用在DDD中。因为DDD中有工厂和仓库来管理领域模型，前者主要用于创建，而后者则用于存储。这就表明在DDD中是默认将读写分离的，DDD似乎就天生和CQRS有着无缝的链接。

CQRS往往要求数据库进行读写分离，具体来说，所有的更新操作均无返回值(void)，而读操作才返回对应的值。在实现CQRS时，又和事件源(Event Source)相结合，以下是一个简单的交互过程：

客户端发起一个请求，服务端将其映射为一个命令，该命令会从仓库中读取一个相关的聚合，对该聚合进行操作，将会生成一个事件源，将该事件发送出去，接收方收到消息后（并不是立刻）将会更新领域对象，完成一次更新操作。

在此基础上，还有称之为六边形的架构风格，它将DDD的领域模型包裹在内，外围含有多种适配器来适配各种通信方式，总体来说，我觉得无论是DDD,CQRS还是六边形，都是一种架构的设计思路，没有绝对的优势，同时也有各自的复杂度，并不容易理解，但有时在软件设计时，不妨多学习一下其中的小细节和思路，必然能够有所收获。

至于能否应用？如何应用？，笔者只能说不能生搬硬套，需要有一定的实践经验才能去尝试，一般情况下，结合项目特点，能适当的灵活采用其中的设计思路即可。

初始DDD(领域驱动设计)相关推荐

C#进阶系列——DDD领域驱动设计初探（五）：AutoMapper使用
前言:前篇搭建了下WCF的代码,就提到了DTO的概念,对于为什么要有这么一个DTO的对象,上章可能对于这点不太详尽,在此不厌其烦再来提提它的作用: 从安全上面考虑,领域Model都带有领域业务,让Cl ...
DDD领域驱动设计之聚合、实体、值对象
关于具体需求,请看前面的博文:DDD领域驱动设计实践篇之如何提取模型,下面是具体的实体.聚合.值对象的代码,不想多说什么是实体.聚合等概念,相信理论的东西大家已经知晓了.本人对DDD表示好奇,没有在真 ...
DDD领域驱动设计 — 贫血模型与充血模型
文章转载来源:https://juejin.cn/post/6917125801460629518 | 前言要想深入掌握和了解 DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念-- ...
DDD 领域驱动设计：贫血模型、充血模型的深入解读！
作者:JavaEdge在掘金链接:https://juejin.cn/post/6917125801460629518 - 前言 - 要想深入掌握和了解 DDD 领域驱动设计的核心, ...
浅谈我对DDD领域驱动设计的理解
从遇到问题开始当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品 ...
DDD 领域驱动设计：贫血模型、充血模型的深入解读
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取后台回复"k8s",可领取k8s资料 - 前言 ...
[转]浅析DDD(领域驱动设计)
最近在做一些微服务相关的设计,内容包括服务的划分,Restful API的设计等.其中比较棘手的就是Service的职责划分:如何抽象具有统一业务范畴的Model,使其模块化,又如何高度提炼并组合多模 ...
浅析DDD(领域驱动设计)
最近在做一些微服务相关的设计,内容包括服务的划分,Restful API的设计等.其中比较棘手的就是Service的职责划分:如何抽象具有统一业务范畴的Model,使其模块化,又如何高度提炼并组合多模 ...
DDD 领域驱动设计落地实践：六步拆解 DDD
引言相信通过前面几篇文章的介绍,大家对于 DDD 的相关理论以及实践的套路有了一定的理解,但是理解 DDD 理论和实践手段是一回事,能不能把这些理论知识实际应用到我们实际工作中又是另外一回事,因此本 ...

初始DDD(领域驱动设计)