对越来越火的DDD,90%的人都理解错的事情!

柴华 2021-08-10 10:25:48
本文根据柴华老师在〖deeplus直播第273期〗线上分享演讲内容整理而成。(文末有回放的方式,不要错过)


我们今天的主题《DDD在哈啰交易中台的实践》,最近几年中台微服务越来越火,DDD虽然作为一种契合中台微服务落地的设计基础,但它的成本极高,除了一些核心概念需要掌握外,对常用的设计思想、代码规范,都需要时间来熟悉和接受。通过这次分享,希望能完善和巩固大家对DDD的基本概念、设计流程和实践经验。

 

接下来从三个方面去介绍DDD。

 

 

一、DDD的基本概念和设计流程

 

 
1、DDD的概念

 

 

DDD的全称是领域驱动设计。

 

在百度百科里面领域的概念是:一种特定的范围或者区域。

 

而在业务场景下,领域是指业务边界,也是指指定范围内待解决的业务问题。在《领域驱动设计:软件核心复杂性应对之道》这本书里面,实际上对DDD的概念、基本流程做了比较明确的阐述。书中说DDD先对领域业务领域进行分析,建立领域模型,根据领域模型驱动代码设计,后面我会对DDD的设计流程去做详细的介绍。

 

 
2、使用DDD的原因和好处

 

  • 核心域:就是公司和团队的核心竞争力。

     

  • 通用域:指的是通用能力。

 

举个例子:比如说当前的公司有个交易团队,打车领域本身是有交易诉求的,那么在打车领域中,交易域可以作为通用域来提供交易的通用能力。

 

  • 第一,它有熟悉成本,它的基本概念、设计流程都是需要熟悉和掌握的;

     

     

  • 第二,它有实现成本,思想和编码习惯的转化,以及分层的增加,都会带来工作量的增加;

     

  • 第三,它的适用场景是有限的,它只适用于解决一些领域问题,以及业务复杂度较高的问题。如果说你当前的团队这三点实际上都不符合的话,我建议是不使用DDD。

 

下面我来讲一下DDD和面向对象,因为DDD和面向对象实际上是匹配的,可以说DDD是面向对象细化版的方法论,从我们前面的讲解可以知道,实体和值对象实际上是类的延伸,而上下文的划分方法是组合和抽象,组合抽象实际上也是面向对象的概念,所以可以说DDD是面向对象细化版的方法论。

 

 

这里给大家提一个思考题:我们在做对象设计的时候经常会用到UML,UML实际上包括类图、状态图、组件图等等。如果我们把UML和DDD结合起来,我们在做DDD的战略设计、战术设计的时候,应该插在面向对象的流程的哪个阶段?

 

 

 
3、DDD的设计流程

 

下面讲一下DDD的设计流程,很多人实际上都说我们先去做战略设计,然后再去做战术设计,因为战略设计会去划分上下文,而战术设计会偏向于技术的细节。

 

但实际上最开始拿到的需求,是有一堆需求列表的,如果我们通过需求列表直接产出上下文,这样划分的领域,以及上下文其实都是不够准确的。一般有领域经验的人会按这种流程设计,如果没有领域经验的前提下,这样去做上下文的划分是非常容易出错的。

 

 

就以《领域驱动设计:软件核心复杂性应对之道》这本书前两章的一个印刷电路板的案例来说,我当时在看这本书的时候,对这个领域实际上是我们没有概念,所以如果在这个阶段直接划分上下文是很危险的。

 

前面我们也讲了DDD的设计流程,针对这种场景下,我们可以做根据需求列表去做需求分析,去做领域梳理,在领域梳理这个阶段我们去梳理一个实体、值对象,以及他们的属性、命令和领域事件,实体和实体的依赖关系,实体和实体的聚合等。

 

然后在第三个阶段,我们通过实体和值对象去反推上下文和领域的划分,具体的方法就是组合和抽象,然后再进一步的去做详细的技术方案以及代码的落地。

 

 
4、DDD、微服务、中台和平台之间的关系

 

 

首先我先讲一下中台和平台,平台的概念是解决公共能力的复用问题,防止公司重复造轮子;中台的概念实际上就是将各个能力去串联成一个平台产品,为前端提供一个业务需求方案。“中台是企业级能力复用平台”这句话,我认为是比较中肯的。

 

拿交易平台来举例,交易平台提供售前、售中、售后能力,而业务线去串联我们各个域的能力,去完成他们的业务流程,这是交易平台要做的事情,而交易中台是依赖交易平台的基础能力,在两个方面其实做了改进:

 

第一点是在流程编排上,在流程编排上为前台提供一个从售前到售中到售后能力的一个串联,它是跨服务的。

 

第二点是接入的便利性维度上,提供了从前端到后端可配置、可扩展的一个便利的交易解决方案,这是我对交易中台的一个理解。

 

 

最后我们来看一下第一DDD、微服务、平台、中台的关联关系。首先平台和中台在业务架构上,实际上更多的是偏向于业务模型的,而形成平台和中台的过程,实际上也是业务领域不断细分的一个过程

 

那么在这个阶段要将通用能力不断的去做聚合、建立领域模型,这个过程实际上和DDD的战略设计实际上是很匹配。

 

当平台和中台完成领域建模之后,我们就需要通过微服务去完成系统架构,而此时DDD的架构设计和微服务的设计是完美契合的,所以可以说平台、中台以及微服务是DDD的一个落地的最佳场景,这也是DDD最近比较火爆一个原因。

 

>>>>

Q&A

 
Q1:领域服务是否可以领域服务是否可以直接调用Repository层,这样的话领域服务不是更加内聚吗?

 

 
A1 :我拿这个图来举例,这个图里面所表述的领域层里面的领域服务,本身就可以调用存储层的接口,存储层本身是在基础设施层实现的,所以你的这个问题是可以的,领域服务是可以去直接调用存储层的。

 

Q2:间限界上下文的识别对业务的场景是否会有影响?

A2:首先在标准DDD的设计过程中,限界上下文对业务的场景是一定会有影响的,因为正常的限界上下文是用来去指导系统设计的,如果你系统架构设计本身会设计的不一致的话,对业务的场景是一定会有影响的。

 

Q3:识别实体和实体关系之后,划分上下文的依据是什么?

A3:

 

 

我可以先看一下这个图,我们在上一步已经去做了实体和聚合的分析和设计,所以我们是通过实体和聚合去往上拆分上下文的,也可以从上下文去往上去划分成更高层的领域。这个方法主要是两种,第一种就是组合,第二个就是抽象。

 

 

前面讲了一个确定上下文的例子,我们可以通过两种方式去做上下文的梳理,第一个是我们实体和实体之间是否存在依赖关系,如果他们存在依赖关系,且组合之后可以形成一个更高层次的领域,就可以通过组合的方式去形成。

 

而另一种比如说像告警和风控,它本身是没有太大的关联关系的,所以我们通过抽象去向上划分。

 

Q4:请教下,DDD适合做游戏开发的服务架构吗?感觉微服务化影响的RT,而且分布式事务也不好做。

 

A4:其实我在最后讲过这个问题, DDDD本身和微服务只是有指导关系。

 

 

DDD其实是可以指导微服务的落地的,但并不代表只有通过微服务才能做DDD的设计,它们是没有反向的推导关系的。

 

 DDD的落地其实不一定是要通过微服务的方式去做落地,而且DDD本身是一个设计的概念,我们可以不用纠结DDD和代码的最终落地。你讲的影响RT、分布式事务,这些实际上都是微服务的问题。

↓点这里可回看本期直播
http://http://z-mz.cn/308Q1

最新评论
访客 2021年09月03日

有没有1000多张表

访客 2021年08月28日

metrics =》 metrix 错误

访客 2021年08月25日

只看到如何避免,如何减少书写慢 sql

访客 2021年08月25日

没看到如何治理呀

访客 2021年07月23日

果然k8s不是神!

活动预告