DDD架构设计知道（5）之用户故事与事件风暴）

比如用户故事它的目标结果导向是用户价值，从而经常使用如“作为xxx主体),我希望xxx（做什么)，以便于xxx（用户价值）”的语句书写“故事“。而事件驱动的结果导向是已发生的事件（动词过去分词表示）。它先分析一些目标结果事件，串联起一个业务全景事件流，继而对因果关系的推倒，梳理出主体、对象（客体）、读模型、策略、决策、事件的几个要素从而形成设计模型。

2、 卡片工作坊形式的集体智慧

白板上卡卡片的便捷性，可以随时将集体的思路方便的调整。大家集思广益的讨论有助于充分发掘业务需求。提炼业务价值。沉淀领域资产。

3、 运用归纳法

归纳法是逻辑分析的方式之一，它从特殊性推导到一般性。用户故事详尽搜集对每个需求的目标价值及如何实现为引导。事件风暴通过因果倒推，构建业务全景。 两则继而分析实体间关系等。提炼共性关系、行为及事件。

4、 状态与事件的一体两面

状态与事件在业务层面也是一体两面的。状态因事件的发生而改变。而状态的改变又再促成事件发生的条件。因此事件总有状态所伴随改变，而状态的改变总会有事件的发生。因果一直在如此循环发生。用户故事的分析更多倾向于实体状态驱动的分析，而事件风暴更多倾向于事件驱动分析。（状态与事件的关系可看这里一篇)

二、 区别点

1、 分析角度不同

用户故事基于用户价值目标由上而下的分析分解故事US，抓住5w1h关键点，继而分解形成每一步的"动名词结构"的TASK。事件风暴通过由底向上的抽象聚合。根据事件相关性划分边界上下文。可以将关注的事件细节拆分成可开发的部分。比如策略 决策 事件等。可发现外部系统事件。

2、 状态驱动设计与事件驱动设计

状态驱动设计中通常以但实体对象的生命周期内，经过事件后的状态变化为主绘制状态图，多对象的状态图由每个单对象组合而成.而事件驱动设计通常以已发生事件为中心，串联事件流，通过事件流经过的客体进行归类分辨出实体对象.

三、 寻找实体对象的重要性.

        不论“动名词方式 ”还是事件中的客体都是在寻找实体 ，那么实体是什么？是我们肉眼可见，能感知的才是实体吗！并不然，eric evens 在他的《领域驱动设计》一书中，一个不起眼的地方 给出了定义“ENTITY（实体）——一种对象，它不是由属性来定义的，而是通过一连串的连续事件和标识定义的。”（题外话：其实任何学问都是相通的，其实到了哲学层面分析的实体，和王阳明说的“事上炼”是一个道理.如果你是个有生命周期的实体，那基本上都必须在经历事情，差别仅仅有的是有思想能反思的生物，有些就是历来顺受的动植物）

四、 适用总结

       目前国内以产品经理为主导的新需求或优化需求通常以用户故事分析方法为开始。 而以架构师技术为主导的老系统改造升级，逆向工程等可以已事件风暴分析方法未开始更为合适。

     用户故事us与事件风暴es各有其优缺点 。而最终两者方法论可以互相促进，相互映证，查漏补缺。让需求分析更为完善。

个人便捷版-用户故事分析法:

       作为..（主体who）我希望..（做什么what）.以便于（达成目标价值why），分解出how 怎么做 ，when 什么时间做，where 在哪做.

事件因果律

个人便捷版-事件驱动分析法：主体 对象 读模型 策略 决策 事件结果。