软件工具: plantUML + tmorin-plantumml-libs
案例1: 故障申报系统
案例2: 奖金申请系统
事件风暴建模要素：
1，人员（利益相关者）全部到齐。 （产品、开发、测试、需求方...）
2，事件粒度。优先识别关键事件，微小事件临时记录的方式。（小事件可能在重要事件识别过程中被认知）
3，以业务专家话术为主。 事件是否属于关键事件、业务的描述词等。（纯粹沟通业务，预防技术人员思维惯性）
4，单次风暴建模不宜讨论多个/大量业务流程
5，角色-命令-事件连线时，使用事件流的形式（不推荐同时进行多角色连线，容易在设计上陷入困难。 例如：角色r1和r2在M命令中存在不同的支线）
6，使用英文对描述进行统一，防止后续话术变化。 (英文可以直译到代码，且不会像中文产生过多的语境)
7，确认流程闭环
8，【问题域-模型】构建完成后，可以考虑【潜在机会点】， 例如简化操作复杂度，新增监听节点等等
9，保持开放、包容、拥抱变更的心态
事件风暴建模优势：
1，从问题域出发的， 结合业务专家、技术等人员，集中精力共同决策，的业务模型
2，快速准确的决策内容（非头脑风暴式来回花费几周事件确认的内容）
3，细化后的模型可直接用于编程，方便TDD开发
4，业务模型的创建为业务变更提供快速响应的能力
最最重要：
【事件驱动建模】是为了得到真实可用可靠的业务模型为目的的，而业务模型构建的全过程是可用根据不同的人群进行拆分的，这样才能满足【真实世界】的种种情况
以往，我们都是以理想情况出发，以【人都不会拒绝对自己有好处的事务】为宗旨，但好的东西是慢的、是需要过程的，我将在这里给出以下几点【视资源而定的事件驱动建模】：
' 1 全体人员都知道。都想知道，都积极参与 （理想情况）
' 2 仅技术团队参与。这需要增加团队之间的沟通，但本模型还是可用 （现实场景1）
' 3 仅某老员工架构师使用。 这将对以往的业务进行总结，得到优化和新的机会点， 还可以得到业务文档，我相信这么做的个人慢慢将成为该系统的中心人物 （现实场景2）
' 4 新进员工使用。 可通过识别事件快速形成真实的业务流，逐步填充全部的业务模块， 不用在成千上万行的代码中一个一个寻找，他将快速成为系统的掌握着 （真实场景3）
' 5 产品经理使用。管控产品进展以及限制增长，将最好的资源放在最大的价值点上（非技术人员）
' 6 项目经理使用。管控项目进展以及新增友好增长点，控制进度、需求方案、风险、机会点等，帮助真实落地（管理人员）
' 7 需求方使用。 友好沟通，直抒需求和想法，在真正的业务上进行编排。 让需要描述成需求，而不是描述成问题。 也为后期变更提供稳健的信息（模型，模型关联，团队开发速度等等）（需求方）
' 以上的真实情况是可用相互作用的，这将加快团队的形成，帮助系统快速稳健地响应变更，降低人力成本（业务能力和技术能力的矛盾得到解决）。
