一、DDD 是什么？

DDD 全名叫做 Domins drives Design；领域驱动设计。再说的通俗一点就是：通过领域建模的方式来实现软件设计。

问题来了：什么是软件设计？为什么要进行软件设计？

软件开发最主要的目的就是：解决一个问题（业务）而产生的一个交付物（系统）。而软件设计旨在高效的实现复杂项目软件。也就是说软件设计是从业务到系统之间的桥梁。

而 DDD 则是在复杂业务场景下一种更高效更合理的软件设计思维方式和方法论。

二、以前的软件设计思维是什么？

绝大部分从事软件开发的人，不管是在学校还是刚开始工作，都是从 ER 图开始。即直接通过业务设计数据库模型和数据关联关系。这种思维根深蒂固的印在了这些人的头脑里（包括我自己）。因此在软件设计过程中习惯性的直接将业务转化为数据模型，面向数据开发。也就是我们所说的 CRUD。我们有时候也会看到一些博客看到或者听到一些同事在说：这个业务有什么难的，不就是 CRUD 么？

不可否认的是，在软件生命周期初期，通过 CRUD 这种方式我们可以快速的实现业务规则，交付项目。然而一个系统的生命周期是很长的并且维护阶段的生命周期占绝大部分比例。 随着业务的发展，业务规则越来越复杂，通过 CRUD 这种粗暴方式，让工程代码越来越复杂，通常一个方法可能会出现几百甚至上千行代码，各种胶水代码和业务逻辑混合在一起，导致很难理解。

这种系统交接给另一个同学或者新进来的同学后，可能需要花费很长的时间才能理解这个方法，原因就是因为这种胶水代码淹没了业务核心规则。所以在现实场景中，我们经常会听到，上一个开发是 SB，或者自嘲自己是在屎山上面继续堆屎。

三、DDD 思想下的软件设计

DDD 的思想是基于领域模型来实现软件设计。那么，什么是领域模型？领域模型怎么得来呢？

DDD 思想，将软件的复杂程度提前到了设计阶段。基于 DDD 思想，我们的设计方式完全变了。

统一语言

首先，将业务方、领域专家以及相关的产研人员都聚拢在一起，共同探讨出业务场景和要解决的问题，统一语言。来确保所有人对于业务的理解都是一致的。

这里的统一语言不是指某种具体的技术语言，而是一种业务规则语言。所有人必须要能够理解这种统一语言。

战略设计

其次，我们根据待解决的问题空间，进行战略设计。所谓的战略设计就是根据问题空间在宏观层面识别出限界上下文。比如说一个电商业务，我们需要交付一个电商系统，根据电商业务的特点，需要划分出用户、商品、订单、仓储等限界上下文，每一个限界上下文都是一个独立的业务单元，具有完整的业务规则。

识别领域模型

然后，再分别针对上下文内的业务领域进行建模，得到领域模型。在 DDD 思想中，领域模型中通常包含实体、值对象、事件、领域服务等概念。我们可以通过“事件风暴”的方式来识别出这些概念。

注意，“事件风暴”和“头脑风暴”是有区别的。“头脑风暴”的主要目的是通过发散思维进行创新，而“事件风暴”是 DDD 中的概念，其主要目的是所有人一起根据统一语言和业务规则识别出事件。再根据事件识别出实体、值对象、领域服务、指令、业务流等领域模型中的概念。

所谓事件指的是已经发生了的事情。比如用户下了一个订单、用户取消了订单、用户支付了订单等

根据事件，我们可以识别出实体，比如上面这个例子中的订单实体，以及指令：取消、支付、下单等。

程序设计

识别出领域模型之后，我们就可以根据领域模型来指导我们进行程序设计了。这里的程序设计包括业务架构、数据架构、核心业务流程、系统架构、部署架构等。需要注意的是，在进行程序设计时，我们依然要遵循 DDD 中的设计规范。否则很容易走偏方向。

编写代码

有了完整的程序设计之后，我们就可以进行实际的工程搭建以及代码编写了。

这个阶段需要注意的是，我们需要遵循 DDD 思想中的架构设计和代码设计。实际上这个阶段也是非常困难的。因为基于 DDD 思想下的工程架构和我们传统的工程架构不一样。

基于 DDD 思想下，编码过程中我们经常会遇到的一个问题是：这个代码应该放在哪里合适。

工程结构

在 DDD 中，标准的工程结构分为 4 层。用户接口层、应用层、领域层和基础设施层。

DDD 中，构建软件结构思维有六边形架构、CQRS 架构等，它们是一种思想，是从逻辑层面对工程结构进行划分，而我们熟知的 SOA 架构以及微服务架构是从物理逻辑层面对工程结构进行划分，它们有着本质的区别，但是目标都是一样的：构建可维护、可扩展、可测试的软件系统。

代码编写

在 DDD 中，最为复杂的便是领域层，所有的业务逻辑和规则都在这里实现。因此我们经常会遇到一个问题就是代码应该放在哪里。

在具体落地过程中会遇到这些问题，解决这些问题没有银弹，因为不同的业务有不同的处理方式，这个时候我们需要与领域专家们讨论，得出大家都满意的处理方案。

代码重构

没有不变的业务。因此我们需要结合业务的发展而不断迭代更新我们的领域模型，通过重构的方式来挖掘隐形概念，再根据这些隐形概念去不断的调整我们的战略设计以及领域模型。使得整个软件系统的发展也是螺旋式迭代更新的过程。

通过以上的介绍，我们实现 DDD 的过程如下：

四、总结

通过对于 DDD 的理解，其实不难发现，程序员的工作重心变了，程序员其实不是在编写代码，而是在不断的摸索业务领域知识，尤其是复杂业务。

所以如果总是觉得自己在 CRUD，有可能不是你做的业务没价值，而是自己对于业务的理解还不够深；如果总是沉迷于代码编写，可能你的发展空间就会受限了。

作者：京东科技 孙黎明

来源：京东云开发者社区 转载请注明来源