领域驱动设计的概念

​  大家都知道软件开发不是一蹴而就的事情,我们不可能在不了解产品(或行业领域)的前提下进行软件开发,在开发前通常需要进行大量的业务知识梳理,然后才能到软件设计的层面,最后才是开发。而在业务知识梳理的过程中,必然会形成某个领域知识,根据领域知识来一步步驱动软件设计,就是领域驱动设计(DDD,Domain-Driven Design)的基本概念 。

为什么需要 DDD

​  在业务初期,功能大都非常简单,普通的 CRUD 就基本能满足要求,此时系统是清晰的。但随着产品的不断迭代和演化,业务逻辑变得越来越复杂,我们的系统也越来越冗杂。各个模块之间彼此关联,甚至到后期连相应的开发者都很难说清模块的具体功能和意图到底是啥。这就会导致在想要修改一个功能时,要追溯到这个功能需要修改的点就要很长时间,更别提修改带来的不可预知的影响面。 比如下图所示:

  订单服务中提供了查询、创建订单相关的接口,也提供了订单评价、支付的接口。同时订单表是个大表,包含了非常多字段。我们在维护代码时,将会导致牵一发而动全身,很可能原本我们只是想改下评价相关的功能,却影响到了创建订单的核心流程。虽然我们可以通过测试来保证功能的完备性,但当我们在订单领域有大量需求同时并行开发时将会出现改动重叠、恶性循环、疲于奔命修改各种问题的局面,而且大量的全量回归会给测试带来不可接受的灾难。

​  但现实中绝大部分公司都是这样一个状态,然后一般他们的解决方案是不断的重构系统,让系统的设计随着业务成长也进行不断的演进。通过重构出一些独立的类来存放某些通用的逻辑解决混乱问题,但是我们很难给它一个业务上的含义,只能以技术纬度进行描述,那么带来的问题就是其他人接手这块代码的时候不知道这个的含义或者只能通过修改通用逻辑来达到某些需求。

领域模型追本溯源

​  实际上,领域模型本身也不是一个陌生的单词,说直白点,在早期开发中,领域模型就是数据库设计。因为你想:我们做传统项目的流程或者说包括现在我们做项目的流程,都是首先讨论需求,然后是数据库建模,在需求逐步确定的过程不断的去变更数据库的设计,接着我们在项目开发阶段,发现有些关系没有建、有些字段少了、有些表结构设计不合理,又在不断的去调整设计,最后上线。在传统项目中,数据库是整个项目的根本,数据模型出来以后后续的开发都是围绕着数据展开,然后形成如下的一个架构 :很显然,这其中存在的问题如下:

  • Service层很重,所有逻辑处理基本都放在service层。
  • POJO作为 Service 层非常重要的一个实体,会因为不同场景的需求做不同的变化和组合,就会造成 POJO 的几种不同模型(失血、贫血、充血),以此用来形容领域模型太胖或者太瘦。
  • 随着业务变得复杂以后,包括数据结构的变化,那么各 个模块就需要进行修改,原本清晰的系统经过不断的演 化变得复杂、冗余、耦合度高,后果就非常严重。

  我们试想一下如果一个软件产品不依赖数据库存储设备,那我们怎么去设计这个软件呢?如果没有了数据存储,那么我们的领域模型就得基于程序本身来设计。那这个就是 DDD 需要去考虑的问题。

DDD中的基本概念

实体(Entity)

​  当一个对象由其标识(而不是属性)区分时,这种对象称为实体(Entity)。比如当两个对象的标识不同时,即使两个对象的其他属性全都相同,我们也认为他们是两个完全不同的实体。

值对象(Value Object)

​  当一个对象用于对事物进行描述而没有唯一标识时,那么它被称作值对象。因为在领域中并不是任何时候一个事物都需要有一个唯一的标识,也就是说我们并不关心具体是哪个事物,只关心这个事物是什么。比如下单流程中,对于配送地址来说,只要是地址信息相同,我们就认为是同一个配送地址。由于不具有唯一标示,我们也不能说"这一个"值对象或者"那一个"值对象。

领域服务(Domain Service)

​  一些重要的领域行为或操作,它们不太适合建模为实体对象或者值对象,它们本质上只是一些操作,并不是具体的事物,另一方面这些操作往往又会涉及到多个领域对象的操作,它们只负责来协调这些领域对象完成操作而已,那么我们可以归类它们为领域服务。它实现了全部业务逻辑并且通过各种校验手段保证业务的正确性。同时呢,它也能避免在应用层出现领域逻辑。理解起来,领域服务有点facade的味道。

聚合及聚合根(Aggregate,Aggregate Root)

​  聚合是通过定义领域对象之间清晰的所属关系以及边界来实现领域模型的内聚,以此来避免形成错综复杂的、难以维护的对象关系网。聚合定义了一组具有内聚关系的相关领域对象的集合,我们可以把聚合看作是一个修改数据的单元。

​  聚合根属于实体对象,它是领域对象中一个高度内聚的核心对象。(聚合根具有全局的唯一标识,而实体只有在聚合内部有唯一的本地标识,值对象没有唯一标识,不存在这个值对象或那个值对象的说法)

​  若一个聚合仅有一个实体,那这个实体就是聚合根;但要有多个实体,我们就要思考聚合内哪个对象有独立存在的意义且可以和外部领域直接进行交互。

工厂(Factory)

​  DDD中的工厂也是一种封装思想的体现。引入工厂的原因是:有时创建一个领域对象是一件相对比较复杂的事情,而不是简单的new操作。工厂的作用是隐藏创建对象的细节。事实上大部分情况下,领域对象的创建都不会相对太复杂,故我们仅需使用简单的构造函数创建对象就可以。隐藏创建对象细节的好处是显而易见的,这样就可以不会让领域层的业务逻辑泄露到应用层,同时也减轻应用层负担,它只要简单调用领域工厂来创建出期望的对象就可以了。

仓储(Repository)

​  资源仓储封装了基础设施来提供查询和持久化聚合操作。这样能够让我们始终关注在模型层面,把对象的存储和访问都委托给资源库来完成。它不是数据库的封装,而是领域层与基础设施之间的桥梁。DDD 关心的是领域内的模型,而不是数据库的操作。

实战演练如何让DDD落地

​  DDD 概念理解起来有点抽象, 这个有点像设计模式,感觉很有用,但是自己开发的时候又不知道怎么应用到代码里面,或者生搬硬套后自己看起来都很别扭,那么接下来我们就以一个简单的转盘抽奖案例来分析一下 DDD 的应用。

针对功能层面划分边界

​  这个系统可以划分为运营管理平台和用户使用层,运营平 台对于抽奖的配置比较复杂但是操作频率会比较低。而用 户对抽奖活动页面的使用是高频率的但是对于配置规则来 说是误感知的,根据这样的特点,我们把抽奖平台划分针 对 C 端抽奖和 M 端抽奖两个子域。

​  在确认了 M 端领域和 C 端的限界上下文后,我们再对各 自上下文内部进行限界上下文的划分,接下来以 C 端用 户为例来划分界限上下文。

确认基本需求

首先我们要来了解该产品的基本需求

  1. 抽奖资格(什么情况下会有抽奖机会、抽奖次数、抽 奖的活动起始时间) 。
  2. 抽奖的奖品(实物、优惠券、理财金、购物卡…) 。
  3. 奖品自身的配置,概率、库存、某些奖品在有限的概 率下还只能被限制抽到多少次等。
  4. 风控对接, 防止恶意薅羊毛。

针对产品功能划分边界

抽奖上下文是整个领域的核心,负责处理用户抽奖的核心业务。

  1. 对于抽奖的限制,我们定义了抽奖资格的通用语言,将抽奖开始 / 结束时间,抽奖可参与次数等限制条件都收拢到抽奖资格子域中。
  2. 由于 C 端存在一些刷单行为,我们根据产品需求定义了风控上下文,用于对抽奖进行风控。
  3. 由于抽奖和发放奖品其实可以认为是两个领域,一个负责根据概率去抽奖、另一个负责将抽中的奖品发放出去,所以对于这一块也独立出来一个领域。

细化上下文

通过上下文划分以后,我们还需要进一步梳理上下文之间的关系,梳理的好处在于:

  1. 任务更好拆分(一个开发人员可以全身心投入到相关子域的上下文中) 。
  2. 方便沟通,明确自身上下文和其他上下文之间的依赖关 系,可以实现更好的对接。

代码设计

在实际开发中,我们一般会采用模块来表示一个领域的界 限上下文,比如:

  • 抽奖上下文:com.hafiz.business.lottery.*
  • 风控上下文:com.hafiz.business.riskcontroller.*
  • 奖品上下文:com.hafiz.business.prize.*
  • 活动资格上下文 : com.hafiz.business.qualification.*
  • 库存上下文:com.hafiz.business.stock.*

对于模块内的组织结构,一般情况下我们是按照领域对象、 领域服务、领域资源库、防腐层等组织方式定义的。

  • 领域对象-值对象: com.hafiz.business.lottery.domain.valobj.*
  • 领域对象-实体: com.hafiz.business.lottery.domain.entity.*
  • 领域对象-聚合根: com.hafiz.business.lottery.domain.aggregate.*
  • 领域服务: com.hafiz.business.lottery.domain.service.*
  • 领域资源库: com.hafiz.business.lottery.domain.repo.*
  • 领域防腐层:com.hafiz.business.lottery.domain.facade.*

部分代码如下:

抽奖聚合根:

  拥有抽奖活动id和该活动下所有可用的奖池列表,它最主要的领域功能是根据一个抽奖的场景(DrawLotteryContext),通过chooseAwardPool方法筛选出一个匹配的奖池。

package com.hafiz.business.lottery.domain.aggregate;
import ...;
public class DrawLottery {
    private int lotteryId; // 抽奖id
    private List<AwardPool> awardPools; // 奖池列表
    public void setLotteryId(int lotteryId) {
        if (lotteryId < 0) {
            throw new IllegalArgumentException("非法的抽奖id");
        }
        this.lotteryId = lotteryId;
    }
    public AwardPool chooseAwardPool(DrawLotteryContext context) {
        ...
    }
}

奖池值对象:

package com.hafiz.business.lottery.domain.valobj;
import ...;
public class AwardPool {
    private String cityIds; // 奖池支持的城市
    private String scores; // 奖池支持的得分
    private int userGroupType; // 奖池匹配的用户类型
    private List<Award> awards; // 奖池中包含的奖品     public boolean matchedCity(int cityId) {
        ...
    }     public boolean matchedScore(int score) {
        ...
    }     public Award randomGetAward() {
        int sumOfProbablity = 0;
        for (Award award : awards) {
            sumOfProbablity += award.getAwardProbablity();
        }
        int randomNumber = ThreadLocalRandom.current().netInt(sumOfProbablity);
        int range = 0;
        for (Award award : awards) {
            range += award.getAwardProbablity();
            if (randomNumber < range) {
                return award;
            }
        }
        return null;
    }
}

抽奖资源库:

  我们屏蔽对底层奖池及奖品的直接访问,仅对抽奖的聚合根资源进行管理。

package com.hafiz.business.lottery.domain.repo;
import ...;
public class DrawLotteryRepository {
    @Autowried
    private AwardDao awardDao;
    @Autowried
    private AwardPoolDao awardPoolDao;
    @Autowried
    private DrawLotteryCacheAccessObj drawLotteryCacheAccessObj;     public DrawLottery getDrawLotteryById(int lotteryId) {
        DrawLottery drawLottery = drawLotteryCacheAccessObj.get(lotteryId);
        if (drawLottery != null) {
            return drawLottery;
        }
        drawLottery = getDrawLotteryFromDB(lotteryId);
        drawLotteryCacheAccessObj.add(lotteryId, drawLottery);
        return drawLottery;
    }     private DrawLottery getDrawLotteryFromDB() {
        ...
    }
}

防腐层:

  以用户信息防腐层为例,它的入参是抽奖请求参数(LotteryContext),输出为城市信息(CityInfo)。

package com.hafiz.business.lottery.domain.facade;
import ...;
public class UserCityInfoFacade {
    @Autowried
    private CityService cityService;
    public CityInfo getCityInfo (LotteryContext context) {
        CityRequest request = new CityRequest();
        request.setLat(context.getLat());
        request.setLng(context.getLng());
        CityReponse reponse = cityService.getCityInfo(request);
        return buildCityInfo(reponse);
    }     private CityInfo buildCityInfo(CityReponse reponse) {
        ...
    }
}

抽奖领域服务:

package com.hafiz.business.lottery.domain.service.impl;
import ...;
@Service
public class LotteryServiceImpl implements LotteryService {
    @Autowried
    private DrawLotteryRepository drawLotteryRepository;
    @Autowried
    private UserCityInfoFacade userCityInfoFacade;
    @Autowried
    private AwardSenderService awardSenderService;
    @Autowried
    private AwardCountFacade awardCountFacade;     public LotteryReponse drawLottery(LotteryContext context) {
        // 获取抽奖聚合根
        DrawLottery drawLottery = drawLotteryRepository.getDrawLotteryById(context.getLotteryId());
        // 增加抽奖计数信息
        awardCountFacade.incrTryCount(context);
        // 选中奖池
        AwardPool awardPool = drawLottery.chooseAwardPool(context);
        // 抽出奖品
        Award award = awardPool.randomGetAward();
        // 发出奖品
        return buildLotteryReponse(awardSenderService.sendeAward(award, context));
    }
    private LotteryReponse buildLotteryReponse(AwardSendReponse awardSendReponse) {
        ...
    }
}

领域驱动的好处

​  用 DDD 可以很好的解决领域模型到设计模型的同步、演进最后映射到实际的代码逻辑,总的来说,DDD 开发模式有以下几个好处 :

  1. DDD 能让我们知道如何抽象出限界上下文以及如何去分而治之。
  2. 分而治之 : 把复杂的大规模软件拆分成若干个子模块,每一个模块都能独立运行和解决相关问题。并且分割后各个部分可以组装成为一个整体。
  3. 抽象 : 使用抽象能够精简问题空间,而且问题越小越容易理解,比如说我们要对接支付,抽象的纬度应该是支付,而不是具体的微信支付还是支付宝支付。
  4. DDD 的限界上下文可以完美匹配微服务的要求。在系统复杂之后,我们都需要用分治来拆解问题。一般有两种方式,技术维度和业务维度。技术维度是类似 MVC 这 样,业务维度则是指按业务领域来划分系统。 微服务架构更强调从业务维度去做分治来应对系统复杂度, 而 DDD 也是同样的着重业务视角。

总结

​  其实我们可以简单认为领域驱动设计是一种指导思想,是一种软件开发方法。通过 DDD 我们可以将系统结构设计的更加合理, 以便最终满足高内聚低耦合的要求。在我的观点来看,有点类似数据库的三范式,我们开始在学的时候并不太理解,当有足够的设计经验以后慢慢会体会到三范式带来的好处。同时我们也并不一定需要完全严格按照这三范式去进行实践,有些情况下是可以也需要灵活调整的。

  公众号中,我们正在进行第一次的赠书活动,本期要赠出的三本书为:《Spring Cloud实战》、《Spring Cloud与Docker微服务架构实战》、《架构探险-轻量级微服务架构》。欢迎大家到公众号中去参与赠书活动,活动有效期三天哈~

推荐两篇不错的DDD文章:

https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html

https://blog.csdn.net/k6T9Q8XKs6iIkZPPIFq/article/details/78909897

可以落地的DDD到底长什么样?的更多相关文章

  1. 可落地的DDD(3)-如何利用DDD进行微服务的划分

    摘要 前面两篇介绍了DDD的目标管理.DDD的工程结构调整.这篇讨论微服务的划分.微服务是目前后端比较流行的架构体系了,那么如何做好一个微服务的划分?一个微服务的粒度应该是多大呢?这篇主要介绍如何结合 ...

  2. 漫画赏析:Linux 内核到底长啥样(转)

    知乎链接:https://zhuanlan.zhihu.com/p/51679405 来自 http://TurnOff.us 的漫画 “InSide The Linux Kernel” 本文转载自: ...

  3. 【随笔】CLR:.net的类型,内部到底长啥样?

    前言 一提到.net的类型,首当其冲的就是“引用类型”.“值类型”:我们在面试中,也会经常被问“来说说值类型和引用类型....”,这时候第一反应就是:“哎呀,这还不简单,值类型是传递的值的copy,值 ...

  4. 可落地的DDD(4)-如何利用DDD进行微服务的划分(2)

    摘要 在前面一篇介绍了如何通过DDD的思想,来调整单体服务内的工程结构,为微服务的拆分做准备.同时介绍了我们在进行微服务拆分的时候踩过的一些坑. 这篇介绍下我们最终的方案,不一定对,欢迎留言讨论. 微 ...

  5. 可落地的DDD(7)-战术设计上的一些误区

    背景 几年前我总结过DDD战术设计的一些落地经验可落地的DDD(5)-战术设计,和一次关于聚合根的激烈讨论最近两年有些新的落地体验,回过头来发现,当初对这些概念的理解还是没有深入,这篇文章重新阐述下. ...

  6. 可落地的DDD(5)-战术设计

    摘要 本篇是DDD的战术篇,也就是关于领域事件.领域对象.聚合根.实体.值对象的讨论.也是DDD系列的完结篇. 这一部分在我们团队争论最多的,也有很多月经贴,比如对资源库的操作应该放在领域服务还是领域 ...

  7. 再深入一点|binlog和relay-log到底长啥样?

    上一篇mysql面试的文章之后收到不少朋友的意见,希望深入讲讲复制.日志的格式这些,今天,我们就来深挖一下mysql的复制机制到底有哪一些,以及binlog和relay-log的结构到底是什么样子的. ...

  8. 可落地的DDD的(2)-为什么说MVC工程架构已经过时

    摘要 mvc是一种软件设计模式,最早由Trygve Reenskaug在1978年提出,他有效的解决了表示层,控制器层,逻辑层的代码混合在一起的问题,很好的做到了职责分离.但是在实际的编码实践过程中, ...

  9. 可落地的DDD代码实践

    目录 前言 一.从六边形架构谈起 二.依赖倒置 三.DDD 代码分层 3.1 用户接口层 3.2 应用层 3.2 1 Response vs Exception 3.2.2 CQE vs DTO 3. ...

随机推荐

  1. s6-5 TCP 连接的建立

    TCP 连接的建立 采用三次握手建立连接 一方(server)被动地等待一个进来的连接请求 另一方(the client)通过发送连接请求,设置一些参数 服务器方回发确认应答 应答到达请求方,请求方最 ...

  2. Exp5 MSF基础运用 20154320 李超

    实验后回答问题 用自己的话解释什么是exploit,payload,encode. exploit:起运输的作用,将数据传输到对方主机. payload:其实就是指装载的“具体内容”.就相当于shel ...

  3. 逻辑回归 vs 决策树 vs 支持向量机(I)

    原文链接:http://www.edvancer.in/logistic-regression-vs-decision-trees-vs-svm-part1/ 分类问题是我们在各个行业的商业业务中遇到 ...

  4. 20155326《网路对抗》Exp8 WEB基础实践

    20155326<网路对抗>Exp8 WEB基础实践 实践内容 (1).Web前端HTML(0.5分) 能正常安装.启停Apache.理解HTML,理解表单,理解GET与POST方法,编写 ...

  5. 中触发一个断点 其原因可能是堆被损坏,这说明 ***.exe 中或它所加载的任何 DLL 中有 Bug

    软件中使用了DevComponents.DotNetBar2.dll MessageBoxEx.Show("ddd");运行到这句出现这个错误 : 中触发一个断点 其原因可能是堆被 ...

  6. poj3660 cow contest

    这题主要是传递闭包 题意: n头牛,m次测试,假设a牛赢过b牛,那么说明a牛的能力比b牛强,问你根据输入的m次测试结果,最多能确定多少条牛的排名 大题的思路: 对于 k 牛,比他强的有x头牛,比他弱的 ...

  7. Python3.* 和Python2.*的区别

    许多Python初学者都会问:我应该学习哪个版本的Python.对于这个问题,我的回答通常是“先选择一个最适合你的Python教程,教程中使用哪个版本的Python,你就用那个版本.等学得差不多了,再 ...

  8. Linux时间戳转换成BCD码(转载)

    #include <stdio.h> #include <stdlib.h> #include <time.h> #include <math.h> / ...

  9. 谈谈 TCP 的 TIME_WAIT

    由来 最近有同事在用 ab 进行服务压测,到 QPS 瓶颈后怀疑是起压机的问题,来跟我借测试机,于是我就趁机分析了一波起压机可能成为压测瓶颈的可能,除了网络 I/O.机器性能外,还考虑到了网络协议的问 ...

  10. 【Node100In1】01.去异步,解决掉Node.js万恶的回调陷阱

    Node.js是基于事件驱动编程.异步函数随处可见,其中不乏一些常用库的方法.本例就以js中最常见的setTimeout的为例,试图改善一下回调的书写. 先来看一段伪代码: 我们实现一个需求,每隔一段 ...