浅析领域驱动设计（DDD）——复杂系统如何被简单设计

软件开发前期，通常需要进行大量的业务知识梳理，进而完成软件设计，然后是开发。

这些软件开发周期中，系统分析和设计是分开的，导致需求和成品非常容易出现偏差，两者相对独立，还会导致沟通困难，而DDD开发模式则打破了这种隔阂，在业务知识梳理的过程中，形成某个领域知识，根据领域知识来一步步驱动软件设计。

01 DDD开发模式 VS MVC开发模式

在介绍DDD开发模式之前，我们先来介绍一下常用的MVC开发模式的开发流程：

1.用户需求转化为产品需求

2.需求评审会pm讲解需求转化为研发需求

3.研发人员根据需求进行设计库表结构

4.编写dao层代码

5.编写service代码

6.编写controller代码

根据上面步骤，譬如我们一般会想考虑设计几张表，怎么存储数据，然后建立dao层，service层，controller层来实现这个功能。

但是严格来讲，MVC开发模式本质上是一种面向数据的设计，主要关注数据，自低向上的思想。

而DDD开发模式就是领域驱动，自顶向下，关注业务活动。

02 使用DDD的意义

DDD 全称是 Domain-Driven Design，是一套应对复杂软件系统分析和设计的面向对象建模方法论。

它是一种处理高度复杂领域的设计思想，不是一种架构，而是一种架构设计方法论，是一种设计模式。说白了就是把一个复杂的软件应用系统的其中各个部分进行一个很好的拆解和封装，以达到高内聚低耦合的这样一个效果。

虽然在开发速度上有一定优势，如果只追求开发速度，面向数据模型编程在短期之内可以搞定需求，但一味追求速度，如果你系统的业务变化快速，从长远来看随着时间的增长，系统堆了杂七杂八以后，MVC的短板就会日益明显。

比如MVC开发模式一些常见的问题有：

• 新需求的开发会越来越难。

• 代码维护越来越难，一个类代码太多，这怎么看对吧，就是一堆屎山。

• 技术创新越来越难，代码没时间重构，越拖越烂。

• 测试越来越难，没办法单元测试，一个小需求又要回归测试，太累。

而DDD开发模式的出现就是为了解决这些问题，从一个软件系统的长期价值来看，就需要用DDD开发模式，虽然一开始从设计到开发需要成本，但是随着时间的增长，N年以后代码依然很整洁，利于扩展和维护，高度自治，高度内聚，边界领域划分的很清楚。

03 如何应用DDD开发模式

当然了，针对于简单的系统用DDD开发模式反而用复杂了，杀鸡焉用宰牛刀！

通过上图我们可以看到，DDD开发模式分层架构中的要素其实和三层架构类似，只是在 DDD开发模式分层架构中，这些要素被重新归类，重新划分了层，确定了层与层之间的交互规则和职责边界。

如何建立领域知识(Build Domain Model)

到底什么是领域模型呢？

以飞机航行为例子：

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

你可能会听到诸如起飞，着陆，飞行冲突，延误等领域名词，让们从一个简单的例子开始（就算是错误的也没关系）：

起点－>飞机－>终点

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

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

既然点构成线，那何不：

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

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

如何形成通用语言(Ubiquitous Language)

上面的例子的确看起来简单，但过程并非容易：

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

所以，在建立领域知识的时候，开发人员和领域专家必须要交换知识，知识的范围范围涉及领域模型的各个元素，如果一方对模型的描述令对方感到困惑，那么应该立刻换一种描述方式，直到双方都能够接受并且理解为止。

在这一过程中，就需要建立一种通用语言，作为开发人员和领域专家的沟通桥梁。

可如何形成这种通用语言呢？

答案并不唯一。

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

b)伪代码将现有模型映射到代码层面，这对人的要求也很高，并不容易实现。

04 DDD开发模式的优势

将DDD开发模式放进实例之后，我们可以清晰看到DDD开发模式的优势，比如：

• 可以根据领域模型界限上下文边界快速拆分微服务，实现系统架构适应业务的快速变化。

• 是一套完整而系统的设计方法，它能带给开发者从战略设计到战术设计的标准设计过程，使得设计思路能够更加清晰，设计过程更加规范。

• 善于处理与领域相关的拥有高复杂度业务的产品开发，通过它可以建立一个核心而稳定的领域模型，有利于领域知识的传递与传承。

• DDD开发模式的设计思想、原则与模式有助于提高开发者的架构设计能力。

• 更方便与业务进行沟通

• 更方便测试

但同样的，也因为DDD开发模式生来就是为了解决复杂问题的，面对简单的系统难免会差强人意，比如：

• 系统改造成DDD开发模式复杂，开发熟悉DDD开发模式思想困难，增加了开发量和维护成本

• 建立领域知识时，开发人员和领域专家在沟通过中的成本高

因此在实际运用中，也不可以盲目的使用DDD开发模式；在合适的场景选择与之搭配的模式才可以达到效率最大化。

鼎道智联作为一家致力于成为业界领先的软件服务商和云计算解决方案提供者，也在努力探索时下新兴技术，并将它们整理分享给大家~

鼎道智联将“助天下人尽享智能物联服务”作为己任，专注于打造出全新的软硬件生态。鼎道自研的DingOS系统，积极尝试各类新兴技术，为各个开发者提供更便利的研发空间，为用户提供更优质的服务体验。我们期待着鼎道智联带来更多惊喜，创造更多的可能性。欢迎各界关注并加入鼎道智联，我们一起探索和前进。