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

Posted 2021-11-04 慕枫技术笔记

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了DDD领域驱动设计落地实践系列：初识DDD相关的知识，希望对你有一定的参考价值。

引言

笔者在经历的很多项目中都使用了DDD领域驱动设计进行架构设计，尤其是在业务梳理、中台规划以及微服务划分等方面，DDD是重要的架构设计方法论，对平时的架构设计有非常好的指导作用。从本文开始笔者将通过一系列的文章阐述自己对于DDD的理解以及如何在项目实战中落地实践DDD。本文作为系列文章的开端，主要和大家聊聊DDD的一些基本概念以及常用方法。

DDD到底是何方神圣？

软件设计方式

我们的软件开发模式可以分为几种类别，分别是DL驱动开发、数据驱动设计以及DDD驱动设计。实际上就是代表了我们不同的开发阶段，有种从粗犷到精细的阶段晋级的感觉。这就好比一个初入职场的萌新，到有一定经验的老鸟，再到精英的打怪升级过程。下面我们分别来看下这几种软件开发模式。

DL驱动开发：即DeadLine驱动开发，给定一个截止日期，只要在这个DL之前完成所需要的功能就可以，至于设计的什么的不关注，基本缺乏过程管理，只追求短期的业务目标，因此对应的代码可能就是一坨一坨的，难以扩展维护，给日后埋下巨大的技术坑。

数据驱动设计：这大概是我们最常用的软件设计方式，需求过来后先进行数据库表设计，再通过数据流向去串联对应的业务流程，基本可以应付大多数的应用服务场景。

DDD领域驱动设计：我们接触的系统越来越庞大了，涉及的子系统也越来越多了，传统的软件设计方式已经不能满足我们应对复杂系统的设计。而DDD提供了我们应对大型复杂系统的领域建模以及分析的方法论。

第一种方式咱们就不说了，我们可以来看下数据驱动和DDD领域驱动设计。其实这两种设计方式最大的不同就是设计思想的转变。基于数据驱动的设计方式关注具体的业务数据承载，先通过确定对应业务的数据实体，而后完成数据库表的设计，再通过具体的业务流程把这些数据连接到一起从而完成软件设计。在一些简单的小的系统中，使用这种设计方式完全够用了。
但是随着业务不断的发展，微服务的落地实践，特别是大厂中极其复杂而又庞大的业务。光靠数据驱动设计难以实现。而DDD关注领域模型，通过领域模型驱动整个系统的软件设计，让那个领域模型与数据模型解耦，明确业务边界，从而能够更好的指导我们完成复杂系统的架构设计。

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必须满足以下两个条件：

1、统一认识：DDD不是谁的独角戏，需要整个团队自上而下对于DDD有比较深刻的理解以及认同。虽然DDD是架构技术实践，但是其正向价值最终会传到业务端形成相应的业务价值。
2、贯彻实施：有了理论指导和深刻认识还不够，我们还必须在实际工作中进行贯彻实施，也许这个过程会有阵痛，但是只要熬过去，对于整个团队来说，必定是架构设计层面的一次跃升。

另外补充说明一下，DDD本身在理解上面就有一定的门槛，即便我们把各种概念都理解了，也不一定就能把DDD在我们的实际工作中完美落地，因为它不仅仅关乎软件架构设计，更是整个团队如何进行贯彻实施的问题，我想这也是DDD没有大规模应用的原因。

为什么需要DDD？

通过上文，我们对DDD有了初步的了解，知道他是一种应对软件复杂度的架构设计方法论。那我们先来看一个问题，那就是到底哪些因素导致了软件设计的复杂性。因为只有搞清楚了软件复杂度的因素，我们才能更加理解我们为什么需要使用DDD来应对越来越复杂的软件系统设计。
我们在实际的项目开发中经常会遇到这样一些问题，经常为了到底这部分业务是你的小组负责修改还是对方小组的修改而吵得脸红脖子粗，

业务复杂度高

需求堆积如山，业务规模随着时间的推移也在不断增长，系统又很庞大，不同业务之间相互影响。就拿电商业务来说，就有商品服务、用户服务、库存服务、订单服务、积分服务、优惠券服务、物流服务等等几十个微服务类别，组成了非常复杂的业务系统。
业务系统多的情况下，业务边界由于历史原因也存在划分不清晰的问题，系统之间各种依赖。一旦来了个牵扯很多子域系统的大项目的时候，经常会因为业务边界问题，团队之间扯的脸红脖子粗，实在劳心劳力。

业务需求变化快

互联网行业各个业务板块竞争都非常激烈，谁能更快推出更加便捷、更加符合用户预期的产品，谁才抢夺市场，占领市场先机。因此相应的商业流程自然变化快，业务今天是这样的流程，明天就变了。这种不断变化的场景以及需求对整个软件系统带来了非常大的设计挑战。

跨团队协作难

一个大项目，很大情况下需要各个子域的团队进行通力合作才能完成，来完成业务的全链路。如果没有统一的业务语言，那么必定导致团队之间的沟通效率低，甚至出现业务传达层层递减的情况。团队之间的反复沟通也会增大设计人员、开发人员的沟通成本。
如上所述，我们在设计软件架构的时候需要考虑到如何更好的实现需求、更好的应对不断变化的需求以及更好的和他人协作来实现。因此传统的数据驱动设计的方式无法满足我们的实际需要了，要是有一种架构设计模式可以支撑我们应对上述的这些挑战的话，那该是多么幸福的一件事情。
因此，综上所述，我们需要一套架构设计的方法论来指导我们进行复杂业务系统的设计，那么DDD就是一个非常不错的选择。

DDD的价值

通过上问的描述，我们大概知道了为什么需要使用DDD来实现软件架构设计。那么DDD会给我们带来怎样的价值呢？
统一业务语言：通过使用统一的领域语言，消除了团队间的分歧，提升团队间的沟通效率。
沉淀业务知识：通过领域模型沉淀领域知识，提升业务建模能力，清晰表达业务核心语义。
清晰业务边界：统一各个子域的认识，通过领域模型界定需求实现边界，表面无休止的团队之间扯皮，拉通团队认知。
提升变化应对：通过领域模型与数据模型的分离，将核心业务的不变与需求的变进行有效隔离，提升架构应变化的能力。

DDD重要概念

统一语言

秦始皇统一六国之后，首先做的就是在全国范围内进行了文字、度量衡、钱币的统一。其中统一文字，就是为了方便各个地域人们的沟通交流，为实现中国的大一统奠定了基础。

那么在DDD中，就是要在领域专家、设计团队、研发团队中建立一套统一的业务术语体系，让大家对于领域知识在描述层面上达成一致，从而解决各个团队之间的沟通协作问题。这里的统一语言主要体现在两个方面：
（1）统一的领域术语：所谓领域术语就是在该领域内的各个对象在命名上达成一致的共识，例如在库存领域中的SKU，各个团队都知道SKU代表的是库存进出的计量单位，这样在进行业务讨论的时候，一提到SKU大家就都知道它所带代表的含义了，不用再进行过多的解释说明。
（2）统一的领域行为：领域行为就是领域的行为描述，例如在库存域中涉及的货物的上架动作就是属于该领域的特有领域行为，因此我们可以看出来，领域行为是一种从领域模型角度来进行行为的描述而不是具体的实现角度。

领域模型

在搞清楚什么是领域模型之前，我们看下《领域驱动设计》中关于领域的定义。

领域即是一个组织所做的事情以及其中所包含的一切。商业机构通常会确定一个市场，然后再这个市场中销售产品和服务。每个组织都有它自己的业务范围和做事方式。这个业务范围以及其中所进行的活动便是领域。

这个定义看上去有种不明觉厉的感觉，我们还是以大家最熟悉的电商场景来进行说明下。电商系统中以用户购物为例子，用户浏览商品之后，选择了对应的商品进行下单，在生成订单之后，积分服务队用户的购物积分进行增加，库存服务将对应商品的库存进行扣减，优惠券服务向用户发放新的优惠券，物流服务将接管后续的成品物流信息。在这个典型的用户下单购物场景下，用户服务负责提供用户信息以及用户的统一管理，那么关于用户的一切操作都是在用户域完成的，包括用户的名称、密码等信息的维护以及注册、登录等动作的实施。那么我们可以认为这里的用户服务就是用户领域，它是这个电商系统中的一个子域。

对于领域模型来说，我们可能会任务它是一个大而全的能够概括整个业务系统的全能型的模型，实际上不是的，定义这样一个模型也是十分困难的事情。在实际落地实施过程中，我们更加愿意在各个子域中实现领域模型的建立，而这个领域模型就在这个限界上下文中完成实现。

所以说领域模型就是针对某个特定业务领域的软件模型，如电商业务领域中的订单、积分、库存、配送等都是电商业务领域的子域。领域模型通过对象模型描述真实的业务场景，精确表达业务语义，它是实际业务场景中的流通货币。

在整个业务团队中，领域专家、设计人员、开发人员需要对领域模型有统一的认识，大家都认可。在不同的子域中就会有不同的领域模型，那么我们怎么来区分不同的领域模型呢，实际上就是通过限界上下文来进行区分。

限界上下文

这个概念怎么说呢，既好理解，又不好理解。限界上下文是一个显式的概念性边界，我们的领域模型都是此边界中，我们都知道领域模型是使用同一语言描述的软件模型，每个领域模型都有对应的属性和动作，这些属性和动作需要在一个特定的上下文环境中才有特定的意义。打个比方，笔记本在文具领域那么它就是一个纸质的记录工具，同样是笔记本这三个字但是在3C领域中，它指的又是我们常用的笔记本电脑。同样的名称但是在不同的边界上下文中代表的含义是完全不同的。因此实际上，限界上下文为团队创建了一个建模边界，团队成员在边界内部实现解决方案。

通过上面的例子我们可以把限界上下文理解为一种农场中的圈子，有的圈子是养猪的、有的圈子是用来种植蔬菜的，如果没有限界上下文那么猪就有可能把蔬菜吃过了，但是有了围栏（限界上下文）之后，我们可以在不同圈子中进行喂养或者灌溉，互不影响从而使得农场可以很好的运转起来。农场的圈子和围栏我们可以实实在在看的到，那么到了软件系统中领域边界就是一种抽象视图。