通过捕捉系统中信息额度改变，再发掘触发这些改变的源头。然后通过这些源头发现背后参与的实体与操作，最终完成对系统的建模。
基本原则
通过事件表示交互
模型偏重于数据角度，描述了在不同业务维度下，数据将会如何改变。而业务维度中的流程、交互、功能点，则更关注行为。而事件（Event），可以有效地弥合数据和行为之间的差距。
比如支付这个行为。我们不需要直接描述支付这个行为，而是通过捕捉这个行为前后的事件：支付发起（Payment Started）和支付完成（Paid）。要知道，事件自身能表达的含义有限，但是将一系列事件按照发生顺序排列起来，就能还原发生过的行为。
构建方式
按照记叙文六要素去想：时间、地点、人物、起因、经过和结果。
- 经过是我们需要表示的行为，不需要出现在模型里；
- 时间可以是事件顺序的依据
- 地点、任务、起因、结果，则是寻找领域概念的依据
以我们常见的电商支付为例：
- 地点没有，也不需要
- 人物就是买家（Buyer）
- 起因是订单（Order），因为需要支付的是订单，那么我们可以吧起因事件（Payment Started）和订单相关联
- 结果是支付凭证（Payment），我们将它与结果事件（Paid）关联。
优点
- 不管是梳理流程的同时发现事件，又或者是通过事件描述流程，建立业务流程或交互流程都是必须的。
- **通过记叙文流要素“时间、地点、人物、起因、经过、结果”**来讲故事，更容易帮助业务方记住领域概念，以及相关的领域情节。