DDD 领域驱动设计落地实践系列：初识 DDD _DDD

引言
笔者在经历的的一些项目中都使用了 DDD 领域驱动设计进行架构设计，尤其是在业务梳理、中台规划以及微服务划分等方面，DDD 是重要的架构设计方法论，对业务领域建模、微服务架构设计有非常好的指导作用。从本文开始笔者将通过一系列的文章阐述自己对于 DDD 的理解以及如何在项目实战中落地实践 DDD 。本文作为系列文章的开端，主要和大家聊聊 DDD 的一些基本概念，让大家对于 DDD 有个整体的认识，在后续的文章中，我们再一步一步去拆解 DDD 的落地实践过程。
DDD 到底是何方神圣？
1、软件设计方式
我们的软件开发模式可以分为几种类别，分别是 DL 驱动开发、数据驱动设计以及 DDD 驱动设计。实际上就是代表了我们不同的开发阶段，有种从粗犷到精细的阶段晋级的感觉。这就好比一个初入职场的萌新，到有一定经验的老鸟，再到精英的打怪升级过程。下面我们分别来看下这几种软件开发模式。

文章插图

DL 驱动开发：即 DeadLine 驱动开发，给定一个截止日期，只要在这个 DeadLine 之前完成所需要的功能就可以，至于设计的什么的不关注，基本缺乏过程管理，只追求短期的业务目标，因此对应的代码可能就是一坨一坨的，难以扩展维护，给日后埋下巨大的技术坑。
数据驱动设计：这大概是我们最常用的软件设计方式，需求过来后先进行数据库表设计，再通过数据流向去串联对应的业务流程，基本可以应付大多数的应用服务场景。
DDD 领域驱动设计：我们接触的系统越来越庞大了，涉及的子系统也越来越多了，传统的软件设计方式已经不能满足我们应对复杂系统的设计。而 DDD 提供了我们应对大型复杂系统的领域建模以及分析的方法论。

文章插图

第一种方式咱们就不说了，我们可以来看下数据驱动和 DDD 领域驱动设计。其实这两种设计方式最大的不同就是设计思想的转变。基于数据驱动的设计方式关注具体的业务数据承载，先通过确定对应业务的数据实体，而后完成数据库表的设计，再通过具体的业务流程把这些数据连接到一起从而完成软件设计。在一些简单的小的系统中，使用这种设计方式完全够用了。
但是随着业务不断的发展，微服务的落地实践，特别是大厂中极其复杂而又庞大的业务。光靠数据驱动设计难以实现。而 DDD 关注领域模型，通过领域模型驱动整个系统的软件设计，让那个领域模型与数据模型解耦，明确业务边界，从而能够更好的指导我们完成复杂系统的架构设计。
2、DDD 是个啥
上文中通过不同软件设计方式的描述，引出了 DDD 领域驱动设计模式，那么我们就来看下 DDD 到底是什么。所谓 DDD 即 Domain Driven Design，字面意思就是领域驱动设计。其实它并不是什么新鲜玩意，早在 2004 年著名建模专家 Eric Evans 在他的颇具影响力的书中《Domain-Driven Design –Tackling Complexity in the Heart of Software》（领域驱动设计：软件核心复杂性应对之道）已经提出来相应的概念。但是实际上国内各个互联网大厂能够把 DDD 应用好的并不多。
DDD 不是一种架构形式，它是一种架构设计的指导思想，是一种应对复杂域问题的方法论。他可以协助我们设计高质量的软件模型。尤其是在复杂、大型软件系统的场景下，DDD 尤其可以发挥其独特的作用。
我们除了理解 DDD 的知识，我们更希望在实际工作中运用这种软件架构设计的思想，但是这并非一件容易办成的事情。想要真正的落地实施 DDD 必须满足以下两个条件
统一认识：DDD 不是谁的独角戏，需要整个团队自上而下对于 DDD 有比较深刻的理解以及认同。虽然 DDD 是架构技术实践，但是其正向价值最终会传到业务端形成相应的业务价值。
贯彻实施：有了理论指导和深刻认识还不够，我们还必须在实际工作中进行贯彻实施，也许这个过程会有阵痛，但是只要熬过去，对于整个团队来说，必定是架构设计层面的一次跃升。