1、引言
上次初步了解了什么是领域事件和为什么要使用领域事件的相关概念，接下来就要继续深入，如何对领域事件建模，
2、事件建模
事件建模也被称为事件风暴，形式有点类似于头脑风暴的方法,通过事件风暴的方法可以快速分析复杂业务领域，完成领域建模的目标。
事件风暴是一项团队活动，是在通过领域事件识别出聚合根，进而划分微服务的限界上下文。在活动中，团队先通过头脑风暴的形式罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对于每一个事件，标注出导致该事件的命令（Command），再然后为每个事件标注出命令发起方的角色，命令可以是用户发起，也可以是第三方系统调用或者是定时器触发等。最后对事件进行分类整理出聚合根以及限界上下文。
事件风暴建模是基于领域驱动设计DDD的业务建模方式，它能够直接分析动态业务流程。动态的业务流程就是说在对于一个状态要做什么样的措施。事件风暴就是开发人员们一起讨论分析哪些状态需要建模领域事件(必须是有价值的)，事件建模的原则是不修改原本代码，保证代码的高度解耦。所以事件建模可以理解为封装，封装的原则就是以不变应万变，不变的是原本的业务，变的是对于业务执行后的状态的处理，例如订单从待付款变为已付款，这个业务本身不变，变的是将支付成功这个结果的应对方法。
建模事件需要知道事件的来源，有因必有果，建模事件必然是有原因和结果的，事件是由事件源和事件处理组合而成的。通过事件源我们来辨别事件的来源，事件处理来表示事件导致的下一步操作。
事件源应该至少包含事件发生的时间和触发事件的对象。事件处理要与事件源进行绑定，所以我们再来定义一个泛型接口。
领域事件不是无缘无故产生的，它有一个发布方。同理，它也要有一个订阅方。
那如何和订阅和发布领域事件呢？ 领域事件的发布可以使用发布--订阅模式来实现。而比较常见的实现方式就是事件总线。 事件总线是一种集中式事件处理机制，允许不同的组件之间进行彼此通信而又不需要相互依赖，达到一种解耦的目的。
3、例子
假如有一个系统代码中存在大量的重复代码，过长函数，过大的类，过长的参数列表，注释不清等问题。实际研发过程中也是经常出现一点改动都可能会引起不可预测的结果，重构势在必行。
但是在重构过程中，没有人可以说清楚现有系统的逻辑，如何重构呢？采用事件风暴的办法，通过对领域中所发生的事情（也就是领域事件）来探索这个领域。
举例来说，能够引发事件的事情包括用户行为（登录、修改密码等）、外部系统所发生的事情（外部接口的回调）以及时间的流逝（某个特定的时间点）。事件也有助于找到领域的边界，对术语的不同阐述可能就意味着存在边界。
准备工作，四色贴纸：
橙色：事件，某个动作的结果，以“XX已XX”的方式表示，比如“用户信息已查询”
蓝色：属性，事件相关的输入、输出数据等
黄色：命令，某个动作，比如“查找用户信息”
绿色：实体，命令的触发者
开始梳理业务，将结果贴到白版上
继续深入梳理，将整个过程的模型、关键数据等梳理出来，贴在白板上 确定重构指导思路，执行重构动作，重构的同时引入单元测试保障重构的质量。
（以上例子原贴：https://www.jianshu.com/p/acb7c8026c21 ）
4、小结
领域事件建模需要做到两点：
-
多人一起讨论商量对业务是否值得建模，分析业务需求，梳理过程。
-
建立领域事件模型（可以以发布订阅订阅模式建立）
对于需要处理的事件，调用事件处理接口，做出相应的处理。
领域事件本质上是对代码的封装，原业务不做任何改动，只调用事件处理接口，以达到解耦的目的，理解了事件建模，需要做到的就是建立领域事件模型来统一处理领域事件。