今日的后端开发，我们常常听到大家提到“领域驱动设计”、“DDD”等名词，听起来感觉很高端，自己也忍不住想了解，但是又不知从何下手。

不慌，我们这个系列的意义就在于用浅显易懂又不是深度的叙述手法，为大家全方位的介绍普及DDD领域驱动设计的知识，并最终落地到自己的项目中。

那么，我们直接进入正题，领域驱动设计（接下来为叙述方便，用DDD代指）到底是什么？

首先，领域驱动设计，顾名思义，它是一种设计的方法论。它的核心在于领域驱动，实际上，它的提出已经有些年头，为何感觉最近突然火了呢？这都离不开微服务的大火。

随着微服务的日益普及以及落地，我们主键发现，盲目的进行微服务拆分非但不能带来显著的受益，反而会使原本的业务逻辑更加复杂，我们急需一种方法理论来知道微服务的拆分。此时DDD进入我们的视线，大家发现，DDD正是一直依赖梦寐以求的适合微服务拆分的指导思想。

经过DDD思想指导之后的微服务架构，更加清晰，代码也更容易维护。

之所以这么说的原因在于，传统的基于事务脚本的代码编写方式，本质上还是单体开发中的流程式开发模式，只是在逻辑上泛泛的进行分离，本质上并没有降低分布式、大并发场景下业务间交互的复杂度，反而由于拆分，增加了代码修改成本，一定程度上增加了需求变更之后，代码腐化的风险。

而同样的业务，在经过DDD领域建模之后，业务边界得到了更为清晰的划分，服务的职责更为条理内聚，后续迭代维护、重构、增加特性的成本显著降低了。

DDD有这么明显的优势，这都得益于它的核心思想：基于面向对象，用软件建模还原了真实世界。

通过领域建模驱动设计的系统，拥有界限清晰的领域模型；代码划分与实际的业务能够很清晰的进行对应，这保证了业务模型与代码模型的深层次映射的一致性。这种一致性的好处在于，确实的将真实世界的交互流程与软件系统的抽象交互逻辑真正对应起来，做到了“在软件层面尽可能的还原了真实世界”。

我们在上文提到说，DDD是一种设计方法论。那么，DDD不是什么呢？

DDD不是某种特定的软件开发框架，它凌驾于具体的开发框架之上，即便我们不引入某种具体的开发框架，如：Spring、Guice之类的框架，仅仅使用原生的编程语言的语法特性，也可以落地DDD。我们说，DDD是框架无关的。

DDD和具体的程序设计语言无关，使用Java/C++/Go/C#等等语言，都能够实现DDD的那些思想，不过，如果语言本身支持面向对象，会更加适合DDD，主要是因为DDD天然体现面向对象。我们说，DDD是语言无关的。

DDD和具体的技术选型无关，这里针对的是更加贴近DDD战术设计的部分，比如说，对于领域事件的实现，我们就有多种方式。可以基于观察者模式直接编码实现、可以直接使用Guava的eventBus实现、也可以使用Spring的事件发布机制，当然，直接基于某种具体的MQ中间件实现也是没有问题的。因此我们说，DDD是技术选型自由的。

了解了DDD是什么，以及它不是什么，我们对DDD有了一个基本的先入为主的认知。此时有些读者便有些兴奋，别急，我们看一下DDD适合的场景再高兴也来得及。

先说结论，DDD既适合简单业务，也适合复杂业务。有些读者忍不住想吐槽我了，这不是废话么。确实不是废话。

DDD的外沿足够支持复杂业务的建模，它被提出的主要目的也是为了解决复杂场景下的业务设计与建模，但是这并不代表它对简单业务无能为力。

我们说，DDD在简单业务场景下也完全适用，只是用DDD得到的受益不那么明显，我们使用传统的事务脚本方式相对来说效率更高更容易落地，毕竟对于开发者而言，学习成本更低。根据奥卡姆剃刀法则，在目的相同的情况下，当然是使用简单的方式对我们受益更加高了。

对于复杂的业务场景，DDD就能够明显的体现出它的价值。比如：电商类业务、支付类业务、营销类业务等。笔者当前从事的广告领域，同样有着复杂的业务场景，涉及到下单、结算、发券、活动、投放、创意、电销等业务场景，DDD对类似于这种复杂综合的业务场景进行建模就会如鱼得水，效果显著。

针对DDD的基本概念，说了这么多，如果只想记住一句话，那么只需要知道：

领域驱动设计是为了解决复杂业务场景下软件建模与领域边界划分的问题而提出的一种基于面向对象的设计方法论，它通过一系列的概念、步骤、方法，确定业务与应用的边界，最终目的为达到业务模型与代码模型的一致性，实现在软件层面还原真实世界的目标。

凡理论的提出到为人熟知都经历了一系列的变更和发展，对于DDD也不例外。我们接着了解下领域驱动设计的发展史。

领域驱动设计这一名词，由埃里克·埃文斯（Eric Evans）在2003发表的《领域驱动设计》一书提出。这本书理论性极强，奠定了领域驱动设计这一综合性软件设计理论的基础。书籍本身也成为DDD的“圣经”，其中文翻译晦涩难懂，有英文阅读能力且想一睹芳容的读者，可以大胆去看英文原本（笔者才识学浅，只看过中文版第一部分内容就甩一边了，改看了《实现领域驱动设计》）。

从《领域驱动设计》一书的首版发表年限我们也能看出，DDD理论本身与分布式、微服务对比，绝对算的上是步入中年的“老大哥”了。

这就是万恶之源：

总结

本文中，我们先入为主的针对领域驱动设计DDD提出了几个问题并一一进行了解答。

初步对DDD是什么，不是什么，DDD要解决的问题，DDD适用的场景做了一个概述讲解。有了这个前提，我们接下来将对软件复杂度进行讲解，并重点对DDD是如何应对软件复杂度这个重要问题进行分析，敬请期待！

---

版权声明：

原创不易，洗文可耻。除非注明，本博文章均为原创，转载请以链接形式标明本文地址。