# 第05节:抽奖策略领域模块开发

作者:小傅哥
博客:https://bugstack.cn (opens new window)

沉淀、分享、成长,让自己和他人都能有所收获!

  • 分支:210814_xfg_strategy (opens new window)
  • 描述:在domain抽奖领域模块实现两种抽奖策略算法,包括:单项概率抽奖和整体概率抽奖,并提供统一的调用方式

# 零、优秀作业

# 一、需求引出设计

需求:在一场营销抽奖活动玩法中,运营人员通常会配置以转盘、盲盒等展现形式的抽奖玩法。例如在转盘中配置12个奖品,每个奖品配置不同的中奖概率,当1个奖品被抽空了以后,那么再抽奖时,是剩余的奖品总概率均匀分配在11个奖品上,还是保持剩余11个奖品的中奖概率,如果抽到为空的奖品则表示未中奖。其实这两种方式在实际的运营过程中都会有所选取,主要是为了配合不同的玩法。

设计:那么我们在做这样的抽奖领域模块设计时,就要考虑到库表中要有对应的字段来区分当前运营选择的是什么样的抽奖策略。那么在开发实现上也会用到对应的策略模式的使用,两种抽奖算法可以算是不同的抽奖策略,最终提供统一的接口包装满足不同的抽奖功能调用。

  • 在库表设计上我们把抽奖需要的策略配置和策略明细,它们的关系是1vn
  • 另外为了让抽奖策略成为可以独立配置和使用的领域模块,在策略表用不引入活动ID信息的配置。因为在建设领域模块的时候,我们需要把让这部分的领域实现具有可独立运行的特性,不让它被业务逻辑污染,它只是一种无业务逻辑的通用共性的功能领域模块,在业务组合的过程中可以使用此功能领域提供的标准接口。
  • 通过这样的设计实现,就可以满足于不同业务场景的灵活调用,例如:有些业务场景是需要你直接来进行抽奖反馈中奖信息发送给用户,但还有一些因为用户下单支付才满足抽奖条件的场景对应的奖品是需要延时到账的,避免用户在下单后又进行退单,这样造成了刷单的风险。所以很时候你的设计是与业务场景息息相关的

# 二、领域功能结构

抽奖系统工程采用DDD架构 + Module模块方式搭建,lottery-domain 是专门用于开发领域服务的模块,不限于目前的抽奖策略在此模块下实现还有以后需要实现的活动领域、规则引擎、用户服务等都需要在这个模块实现对应的领域功能。

strategy 是第1个在 domain 下实现的抽奖策略领域,在领域功能开发的服务下主要含有model、repository、service三块区域,接下来分别介绍下在抽奖领域中这三块区域都做了哪些事情。

  • model,用于提供vo、req、res 和 aggregates 聚合对象。
  • repository,提供仓储服务,其实也就是对Mysql、Redis等数据的统一包装。
  • service,是具体的业务领域逻辑实现层,在这个包下定义了algorithm抽奖算法实现和具体的抽奖策略包装 draw 层,对外提供抽奖接口 IDrawExec#doDrawExec