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

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

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

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

零、优秀作业

• 抽奖策略的细节有些疑问思考后记了点笔记 @阿羲⭐️ (opens new window)
• 抽奖算法整理 @朝北 (opens new window)
• 抽奖策略领域模块开发 @一点江南 (opens new window)
• 第五章策略模式实现抽奖算法 @要学的太多 (opens new window)
• 领域模块开发 @我的旅途 (opens new window)
• 领域模块的实现 @BerserkD (opens new window)
• 抽奖活动策略表设计 @Φ (opens new window)
• 问题：MySQL被入侵、BTC勒索 (opens new window)
• 开发抽奖领域 @奥斯卡最佳配角 (opens new window)
• 抽奖策略领域模块开发 @Geroge Liu (opens new window)
• 抽奖领域模型分成三部分 @liuc (opens new window)
• 抽奖策略，整理下思路 @YOLO (opens new window)
• 为什么单项概率需要散列到长度为128的数组中去而不是直接按顺序插入长度为100的数组 @轻舟故人 (opens new window)
• 对DDD和MVC有了一个分层的认知 @浩 (opens new window)
• 根据业务需求与使用场景设计数据库表 @Jachin (opens new window)
• 今天将昨天的05节的代码实现好好读了一遍，并且了大量的注释在代码中理解 @Jachin (opens new window)
• 在项目结构上总是喜欢和目前公司的mvc进行比较 @稣 (opens new window)
• 这里讲讲重点吧，awardID的存储，怎么进行抽奖概率的初始化这些 @爱奋斗的小鲨鱼 (opens new window)
• 学习本章，花费了3天时间学习，前两天通过面经手册补充了HashMap和ThreadLocal的知识 @Ad. (opens new window)
• 深度学习本章节领域架构、设计模式、算法实现 @learningJ (opens new window)
• 什么是斐波那契散列法？@这 (opens new window)
• 调试 Bug 调了一下午，经验总结 @twinkler (opens new window)
• 学习抽奖算法卡了两天 但收获满满 @D77 (opens new window)
• 抽奖策略领域模块开发，功能xmind梳理 @Ken (opens new window)
• 感觉对DDD架构有了理解，在学习的过程中也见到了许多以前没见过的东西，我把这些记录了一下。 @... ... (opens new window)
• 这几天总结下来，每次进入新章节，先看视频，再看wiki，再看大佬们的作业，结合大家的理解和问题，再去写代码，很有收获。@素质男孩 (opens new window)

一、需求引出设计

需求：在一场营销抽奖活动玩法中，运营人员通常会配置以转盘、盲盒等展现形式的抽奖玩法。例如在转盘中配置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