group-buy-market

KO | EN

gitlite — search

#javascript #python #hacktoberfest #react #ai #typescript #llm #go #golang #android #machine-learning #rust #deep-learning #linux

group-buy-market

★ 14 Open GitHub ↗

An e-commerce group buying marketing system based on DDD design, supporting activity configuration, user participation and settlement, a microservice

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

## 拼团需求分析

在互联网公司中，一个需求首先是从业务侧发起的盈利目标，拆分为不同的运营策略。再把对应的策略由产品经理设计为可以支撑市场运营操作完成盈利目标的具体项目。所以这里有一般有3个角色，包括；业务人员、运营人员、产品经理。他们分别在自己的岗位产生不同的资料，包括；MRD、BRD、PRD。

+ 市场需求文档（MRD）： MRD是从市场的角度出发，描述目标市场的需求和机会。它通常包括目标客户群、市场趋势、竞争分析、市场机会、产品定位以及产品应该实现的市场目标等。MRD通常由产品经理或市场分析师编写，目的是定义产品应该解决的市场问题和满足的用户需求。
+ 业务需求文档（BRD）： BRD更侧重于业务角度，描述业务目标、业务流程、业务规则、业务问题以及业务需求。它是从组织的业务视角来定义需求，包括业务背景、业务目标、影响分析、风险评估等。BRD通常由业务分析师编写，目的是确保项目解决了正确的业务问题，并与公司的业务战略保持一致。
+ 产品需求文档（PRD）： PRD是更详细的文档，它根据MRD和BRD中确定的需求，具体描述产品的功能性和非功能性需求。PRD包括用户故事、用例、功能列表、性能要求、界面设计、用户体验等。PRD通常由产品经理编写，目的是为设计团队和开发团队提供一个明确的、详细的产品实现指南。

而研发最终看到的就是这份 PRD 文档，根据产品对 PRD 文档与各个负责的业务线研发进行的评审，让研发了解本次项目所需完成的工作。之后研发在会后根据 PRD 文档进行详细的设计和系统建模。这一部分前期的工作几乎占据了整个项目周期的50%以上的时间。所以研发写代码，只是众多环节中的一环。

### 一、项目背景

针对目前的`xxx`，商品购买交易同比增速放缓，需要引入新的营销策略促进商品交易量。在交易数据统计分析中得到，市场存在同类竞品，商品价格设定低于目前我们的商品定价，所以用户购买意愿偏低。

所以为了盘活沉睡用户，需要适当降低商品价格。但为了达到传播的效果，所以需要引入拼团方式，以客带客，靠用户自身传播的方式进行交易拉新。这样的处理方式对比于 KOL，会让利商品价值到用户自身。【KOL 等同于抖音大主播直播卖货】

![image-20250223191213174](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223191213174.png)

另一方面，通过本项目的增加，逐步完善功能产品和运营服务体系，优化整体的产品架构，增强市场竞争力。

### 二、产品方案

因为我们所实现的是一个平台类系统，可以满足各类交易场景的拼团需求接入。所以在实现这套系统时候，不要与其他系统耦合。并提供相关的研发侧对接标准。

1. 前端页面

![image-20250223191534158](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223191534158.png)

+ 进入商品页后，查询是否配置了拼团活动。并进行优惠试算，拼团成团价，最低优惠展示。
+ 参与首次拼团、参与拼团中拼团。拼团完成则不在展示此条拼团。
+ 所有参与中的拼团统计拼团人员。

2. 运营管理

![image-20250223191657194](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223191657194.png)

+ 提供配置需要提供如图所示信息。
+ 人群标签为提前设定标签类型，产生对应的人群数据。

3.  功能流程

![image-20250223191739002](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223191739002.png)

+ 首先，由运营配置商品拼团活动，增加折扣方式。因为有人群标签的过滤，所以可以控制哪些人可参与拼团。
+ 之后，用户可见拼团商品并参与拼团。用户可自主分享拼团或者等待拼团。因为拼团有非常大的折扣刺激用户自主分享，以此可以节省营销推广费用。
+ 最后，拼团完成，触达商品发货。这里有两种，一种运营手段是拼团成团稀有性，必须打成拼团才可以。另外一种是虚拟拼团，无论是否打成，到时都完成拼团。

## 拼团库表设计

### 一、库表关系

![image-20250223192216653](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223192216653.png)

+ 首先，站在运营的角度，要为这次拼团配置对应的拼团活动。那么就会涉及到；给哪个渠道的什么商品ID配置拼团，这样用户在进入商品页就可以看到带有拼团商品的信息了。之后要考虑，这个拼团的商品所提供的规则信息，包括；折扣、时间、人数等。还要拿到折扣的一个试算金额。这个试算出来的金额，就是告诉用户，通过拼团可以拿到的最低价格。
+ 之后，站在用户的角度，是参与拼团。首次发起一个拼团与参与已存在的拼团进行数据的记录，达成拼团约定拼团人数后，开始进行通知。这个通知的设计站在平台角度可以提供回调，那么任何的系统也就都可以接入了。
+ 另外，为了支撑这套库表，也会有人群的设计。人群是互联网公司中非常常用的手段，比如要把所有符合某个条件的用户ID，全部写入到一个特定的 Redis 记录中，之后就可以专门为这些人做特定的拼团活动了。
+ 那么，拼团活动表，为什么会把折扣拆分出来呢。因为这里的折扣可能有多种迭代到一个拼团上。比如，给一个商品添加了直减10元的优惠，又对符合的人群id的用户，额外打9折，这样就有了2个折扣迭代。所以拆分出来会更好维护。这是对常变的元素和稳定的元素进行设计的思考。

### 二、库表设计

1. 拼团配置表

![image-20250223193408140](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223193408140.png)

![image-20250223193451259](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223193451259.png)

+ 拼团活动表：设定了拼团的成团规则，人群标签的使用可以限定哪些人可见，哪些人可参与。
+ 折扣配置表：拆分出拼团优惠到一个新的表进行多条配置。如果折扣还有更多的复杂规则，则可以配置新的折扣规则表进行处理。
+ 人群标签表：专门来做人群设计记录的，这3张表就是为了把符合规则的人群ID，也就是用户ID，全部跑任务到一个记录下进行使用。比如黑玫瑰人群、高净值人群、拼团履约率90%以上的人群等。

![image-20250223193847376](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223193847376.png)

![image-20250223193934126](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223193934126.png)

![image-20250223193959274](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223193959274.png)

+ 拼团账户表：记录用户的拼团参与数据，一个是为了限制用户的参与拼团次数，另外是为了人群标签任务统计数据。
+ 用户拼单表：当有用户发起首次拼单的时候，产生拼单id，并记录所需成团的拼单记录，另外是写上拼团的状态、唯一索引、回调接口等。这样拼团完成就可以回调对接的平台，通知完成了。【微信支付也是这样的设计，回调支付结果，这样的设计可以方便平台化对接】当再有用户参与后，则写入用户拼单明细表。直至达成拼团。
+ 回调任务表：当拼团完成后，要做回调处理。但可能会有失败，所以加入任务的方式进行补偿。如果仍然失败，则需要对接的平台，自己查询拼团结果。

## 研发系统设计

### 一、用户用例图

用例图（英语：use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。

+ 用例图，也可以等同于是用户故事（英语：User story）（软件开发和项目管理中的常用术语），主旨是以日常语言或商务用语撰写句子，是一段简单的功能表述。以客户或使用者的观点撰写下有价值的功能、引导、框架来与使用者进行互动，进而推动工作进程。可以被认为是一种规格文件，但更精确而言，它代表客户的需求与方向。以该用户故事来反应对象在组织内的其工作职责、范围、需要进行的任务等。用户故事在敏捷开发方法中用来定义系统需要提供的功能和实现需求管理。
+ 尽管用例本身会涉及大量细节和各种可能性，用例图却能提纲挈领地让人了解系统概况。它为“系统做什么”提供了简化了的图形表示，因此被誉为“搭建系统的蓝图”。

![image-20250223195055294](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223195055294.png)

+ 站在用户视角，会有；查看拼团商品、发起拼团、参与拼团、查看拼团结果、查看商品记录。
+ 站在运营视角，会有；配置拼团活动、配置人群标签、审核拼团配置、查看拼团流水。

### 二、四色建模图

1. 建模方法

![image-20250223195537094](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223195537094.png)

+ 蓝色 - 决策命令，是用户发起的行为动作，如；开始签到、开始抽奖、查看额度等。
+ 黄色 - 领域事件，过去时态描述。如；签到完成、抽奖完成、奖品发放完成。它所阐述的都是这个领域要完成的终态。
+ 粉色 - 外部系统，如你的系统需要调用外部的接口完成流程。
+ 红色 - 业务流程，用于串联决策命令到领域事件，所实现的业务流程。一些简单的场景则直接有决策命令到领域事件就可以了。
+ 绿色 - 只读模型，做一些读取数据的动作，没有写库的操作。
+ 棕色 - 领域对象，每个决策命令的发起，都是含有一个对应的领域对象。

2. 寻找事件

寻找领域事件的过程，就是寻找系统中流程节点的结果态。什么结束了、什么完成了、什么终止。

其实这样的手段，也是一种目标结果驱动的手段，当有人为你指明了，你要去哪里，之后你会有更目标感的前进。

![image-20250223200036747](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223200036747.png)

+ 目前我们可以根据需求找到，如图中黄色部分的领域事件。包括；发起拼团完成、参与拼团完成、拼团目标达成、回调通知完成、拼团发货完成、人群标签生成完成、拼团活动创建完成。
+ 如果后续我们在迭代新的功能的话，还会引入其他领域事件。你也可以思考，还可能存在什么领域事件。

3. 划分领域

![image-20250223200256410](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223200256410.png)

+ 蓝色为以用户维度的决策命令，你发出的所有命令，都会有一个对应的结果态承接。
+ 如果是复杂的业务，要做一些列的流程，则会出现一个 Business Policy 业务流程。这个业务流程里可以通过设计模式来完成功能的设计。经过这样的处理，你的代码也会变得非常清晰。

### 三、业务流程

研发功能流程设计有一粗一细，粗的是流程图为了让大家快速的了解这些功能节点的串联关系，方便讲解的时候，可以让多方了解。细的是UML时序图，这个会把流程中的个细节体现出来，指导研发做功能实现。

1. 流程图

![image-20250223201114417](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223201114417.png)

2. 时序图

![image-20250223201247969](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223201247969.png)

![image-20250223201316063](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223201316063.png)

![image-20250223201335100](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223201335100.png)

### 四、系统架构

DDD 是软件开发设计的一套指导思想，但不是直接决定了你如何编码，而是提供了对需求设计为研发提供编码指引的手段。所以，DDD 建模后，你可以使用3层架构 MVC 开发，也可以使用六边形架构、整洁架构、菱形架构开发。这也就是为什么有些人的简历上，专业技能栏里会有相关架构内容的体现。

在这方面，阿里最早推出的 cola 考拉🐨架构，就是整洁架构的代表。张毅老师推出的菱形架构，南向网关、北向网关，属于六边形这一类的架构。这些都是为了更好的落地 DDD 这套指导思想而出现的架构分层设计。

所以，DDD 是指导思想，帮助你建模设计，划分领域。六边形架构、整洁架构、菱形架构，是为了帮你落地知道思想到具体编码实现上。

那么，MVC 分层架构不也可以开发 DDD 知道思想的编码吗？可以，但相对来说不会那么优雅。MVC 的出现，并不是在有了分布式微服务之后，所以一些分布式资源模块的承载和领域思想的处理，在 MVC 中都是比较别扭的。所以，我们选择新的架构形态可以更好的承载 DDD 指导思想。

![image-20250223201552712](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223201552712.png)

![image-20250223201618144](https://raw.githubusercontent.com/kkkkendei/group-buy-market/main/images/image-20250223201618144.png)

如图，展示了分布式微服务架构项目，各项开发过程中所需的资源在两套分层架构中的体现。

1. MVC 基本是把所有的内容都用服务来承载，无论是自身的服务，还是外部的服务。这样会导致维护混乱，长期迭代成本的增加。
2. 六边形架构，对于MVC的劣势做了针对性的架构处理，合理的划分了各项资源在不同层的承载。domain 也更专注于领域功能的实现。也就是把以前的 service 内容，划分到 domain 中处理。

+ **接口定义-api** ：因为微服务中引用的 RPC 需要对外提供接口的描述信息，也就是调用方在使用的时候，需要引入 Jar 包，让调用方好能依赖接口的定义做代理。
+ **应用封装-app** ：这是应用启动和配置的一层，如一些 aop 切面或者 config 配置，以及打包镜像都是在这一层处理。你可以把它理解为专门为了启动服务而存在的。
+ **领域封装-domain** ：领域模型服务，是一个非常重要的模块。无论怎么做DDD的分层架构，domain 都是肯定存在的。在一层中会有一个个细分的领域服务，在每个服务包中会有【模型、仓库、服务】这样3部分。
+ **仓储服务-infrastructure** ：基础层依赖于 domain 领域层，因为在 domain 层定义了仓储接口需要在基础层实现。这是依赖倒置的一种设计方式。
+ **领域封装-trigger** ：触发器层，用于提供接口实现、消息接收、任务执行等。所以对于这样的操作，小傅哥把它叫做触发器层。
+ **类型定义-types** ：通用类型定义层，在我们的系统开发中，会有很多类型的定义，包括；基本的 Response、Constants 和枚举。它会被其他的层进行引用使用。

group-buy-market

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README