讲故事使人类能够将知识传给下一代，并依赖于我们存储记忆的方式。我们可以通过举例说明，一个系统从开始到结束应该做什么，在时间轴上，而且没有分支。要做到这一点，我们需要用特定的时间线画一条线，代表状态在不同时间的不同变化。为什么是时间？时间是系统的一个重要方面，因为每个应用程序都是一个场景中的分布式系统。现在一切都需要跨洲工作。所以，时间是开发中相当必要的一个方面。
一个能工作的模型能支持利益相关者，也能支持交付团队。由于事件建模描述了一个系统的行为，以这种方式代表模型是理想的。用不同的模型来解释同一个想法会产生很多模糊性。建立一个适用于整个团队的模型，意味着消除所有抽象模型的模糊性。事件模型化的系统解耦了商业基础设施。事件模型代表了用户的意图，与后台使用的技术无关。
依靠事件模型解决方案工作的企业享有对历史数据的操作。这个想法是为了存储业务信息的基本片段。这样的数据使我们能够在任何时候推断出系统的状态。
事件建模用一个信息如何跨时间变化的例子来描述系统。时间轴上的所有事件都描述了系统的行为。这些是时间线上的事件，构成了对系统的描述。
假设你专注于状态，并且为每件事情都有一个位置，以及它将去哪里。在这种情况下，你减少了这种返工，以至于你可以几乎完全遵循开放-关闭原则。这是一个更加协作的方法，也更加专注。这就像一个小的设计，而不是一个广泛的设计在前面，所以我们可以做UML所要做的一切，而没有所有的复杂性和细节。我们必须考虑将使用哪些算法以及代码将如何表现。绿地项目，前两周前两个月很可爱。我们要看的是系统的状态是什么。我们并不关心当我们按下那个按钮时会发生什么。我们知道我们打算注册，并且只存储我们已经注册的事实。无论这是在Ruby、Typescript或任何编程语言中运行都不重要。重要的是，如果我们在那件事发生后关闭了电源，事实就会被储存在系统中。
事件发生在系统中--无论我们是否存储它们，这都是一种选择。使用事件建模，团队可以专注于核心功能，使系统更有效率和成本效益。
事件建模的理念是，我们只关注设计的基本部分，使其变得很小。当我们更新信息时会发生什么？它被删除了。在帮助我们解决问题时可能至关重要的历史片断会丢失。事件模型暴露了我们在哪里有这些损失。试图重构一个代码库的工作是以逻辑的结构为重点的。这将受众限制在只有开发人员。现在可以通过确保我们想要解决的代码区域不会在我们不期望的地方影响状态来显示变化的范围。这种审计允许我们定义我们的重构所要影响的范围。假设我们从传统系统的事件模型中得到足够多的工作流实例数据。在这种情况下，当从头开始重新实现时，我们就更有可能成功。即使我们不存储事件，它们仍然是描述一个系统应该做什么的最有效方式。
开放-封闭系统是有益的，因为它减少了返工。新的功能被添加，而不是重新思考所有的事情都已经完成，然后试图整合新的功能。力求不在事件模型中加入任何代码或逻辑。如果我们遵循信息在系统中随时间变化的证据，我们会对更多的人说话。
事件建模使得软件设计有了专门的协作方法。事件建模根据系统在时间内的转换来描述系统。把事件建模想象成一个故事板。团队正在制作一部关于程序的电影。场景的顺序是设计的走马观花。事件建模通过让每个人对整个系统负责来实现协作。领域事件代表了时间轴上的一系列结果。领域事件代表了建立整个业务流程的当前状态的事实。事件建模与业务演进同步进行，使解决方案更加有效。