学习与尝试 --> 事件风暴

事件风暴

1. 基础概念

术语

1. 执行者 -----> 是指执行的角色，系统的主体，是导致系统状态变化的触发源
   1. 人员，系统的用户，操作人员等
   2. 系统，系统本身执行的，或者调度的，自动触发的 ，第三方系统
   3. 定时任务，定时的触发任务
2. 命令 -----> 是执行者发起的操作，构成要件是执行者的行为
   1. 是某个场景中领域事件的触发动作，对应一个用例
3. 领域对象 -----> 是对对象，人或者系统的信息表示，它通过较为简单的信息结构来代表我们需要理解的复杂事务或系统
   1. 创建订单，修改订单 ，删除订单等 ，领域对象：订单
4. 领域事件 -----> 是和领域相关的事情，实在业务上真实发生的事实，这些事件对系统会产生关键影响，是观察业务系统变化的关键点，领域事件一般是领域专家关心的，一般已动词的过去式表示，表示已发生什么事件，是过去已经发生过的事实
   1. 识别领域事件的线索
      1. 是否产生了某种数据
      2. 系统状态是否发生变化，无论这种状态存放到数据库还是内存
      3. 是否对外发送了某些消息
5. 读模型 -----> 为了达到一个目的，需要在系统中读出一些数据
   1. 读模型来源于领域对象，展现的形式不一样，一个读模型中可能包含多个领域对象

2. 事件风暴工作坊实践流程

• 产品愿景，识别软件价值和定位，进行业务的导入，团队共识业务需求信息
• 初步进行领域划分，识别出核心域，分而治之 ，对问题域的初步划分，分解问题
• 事件风暴，观察业务系统变化的关键点，找出系统状态的变化规律
• 命令风暴，找出系统状态的触发者和行为
• 寻找模型，根据领域名词，设别领域对象，识别对象之间的关系，设计模型
• 限界上下文划分，分解问题 ，战略规划
• 规范化的输出，已团队共识的模型或者UML输出等

3. 步骤

1. 共识白板中的图例，各自表示的是什么

   

2. 从一个初步划分的领域开始 ，按照时间轴，从左到右的，写出事件（对时间的顺序要求不是很高，尽量按照时间的先后顺序识别）

3. 识别命令 ，和 执行者 ，并明确执行者的角色，比如，第三方系统，系统操作人员，定时任务

4. 识别读模型

5. 根据业务识别出来的命令，事件，找出具有代表性的名词，建立初步的模型，并整理分类

6. 识别模型之间的关系，画出领域分析模型

7. 根据分析模型，细化模型，设计出领域设计模型，并用uml展示

8. 根据设计模型 设计 聚合，实体，值对象，细化模型

9. 划分限界上下文 ，规范文档输出

业务需求

愿景和目标，统一认识，对于目标的共识

对于 ：精装管理业务流程的业务人员（销售，订单，财务）

他们想 ：更好的管理客户，项目，订单，以及更快的协作，完成订单，跟踪订单

这个 ：精装订单系统

是一个 ：内部管理系统

它可以 ：通过对客户，项目，订单的在线化管理，提升业务方的协作效率，更好的跟踪 客户 和订单的情况

不同于 ： OA管理系统

它的优势是 ：结合业务的实际运行情况，基于定制化的管理系统，提升效率

1. 需求描述

​ 销售人员 登录APP，如果没有账号则注册账号，登录成功后，可以在系统上录入客户的基本信息，根据客户的房屋信息创建项目，一个客户可以创建一个或者多个项目，销售人员根据客户的意向情况，创建订单，收取意向金，收取的意向金需要财务进行确认，并记录审核的情况, 财务确认后，订单专员可以看到订单列表，审核订单信息，审核未通过，则通知销售人员原因

​ 订单专员可以给订单绑定合同，如果该客户下没有合同，可以为客户创建合同，并绑定，有合同，就直接绑定合同号，绑定的合同号会流转到下游的系统中，订单专员可以填写排期单信息，确定订单没有问题后，可以做订单下达 ，当订单的生命周期完结后，订单专员可以完成订单 ，订单中途出现意外情况 ，可以作废订单

订单状态机：

1. 订单已创建 ------> 订单创建的初始状态
2. 订单已生成合同号 ------> 订单绑定合同号成功
3. 订单已下达 ------> 订单下达成功
4. 订单已完成 ------> 订单完成了
5. 订单已废弃 ------> 比如客户不想在公司做了 等情况 或者 没有用的订单不用跟踪了，废弃订单

2. 规则

1. 意向金：向客户收取的定金 ，可以任意的填写 ，至少收取1千以上
2. 财务审核确认，线上支付的不需要财务确认，现金需要财务进行确认
3. 合同号生成规则：Gr + 年月日时分秒
4. 合同号必须绑定 ，不绑定不能做订单下达
5. 排期单必须填写，不填写不能做点单下达
6. 用户名必须唯一，必须填写电话号码 和邮箱，并验证 ，密码长度不能低于6位

3. 术语

1. 项目：在家装行业，项目的基本信息，一般就是客户的房屋信息，把房屋信息当作项目信息来管理
2. 合同号：合同的标识
3. 下游系统，另外一个服务或者第三方的系统

4. 干系人

1. 销售 ，客户 ，订单专员 ，财务人员

   

2. 分析

   1. 销售是支持者，录入和收集客户的基本信息应该要尽量完善，这样有利于设计师的设计和报价，面向的是客户，挖掘更多的客户信息，有利于签单
   2. 需要对客户进行分层，不同的客户，尽量匹配比较适合的设计师和销售
   3. 财务人员审核的周期控制等
   4. 订单专员审核的步骤可能很繁琐，需要考虑他的痛点以及效率

5. 流程图

6. 领域分析模型

参考资料

感谢各位老师的输出整理

1. 公众号：作者：少个分号，公众号名称：DDD和微服务， https://mp.weixin.qq.com/s/3Ef7jzetIb7r_abH-i4Z8g
2. 51CTO 课程 ，领域驱动设计课程 ---> 事件风暴
3. 解构领域驱动设计 ---> 事件风暴

标签：尝试,--,模型,系统,领域,订单,客户,事件,风暴
来源： https://www.cnblogs.com/lifeng618/p/16557589.html