为何大佬都喜欢用事件驱动进行领域建模？

一、背景

最近看了一些大佬的公众号以及一些培训DDD的宣传课程，发现有很多都在宣传基于事件驱动的领域建模方法，这里就简单分析一下为什么大佬们都喜欢用这个方法来构建领域模型。

二、事件驱动建模

2.1 事件驱动

其实从需求分析和建模的软件开发历史来看我们对业务操作更感兴趣，因为有业务操作才能串联多个领域上下文，盘活整个模型。事件驱动让人们看到了业务操作带来的后置变化的价值，类似于因果关系。更重要的是某件事情发生我们希望明确的知道这件事会引起什么其他事情发生。那么对于事件而言，感观上就是事情发生后的事件，但是扩展一点也可以代表事件本身，相当于语境不同这个词也有不同的指向。

回到事件本身，我们更容易对业务流程中的多个节点通过事件表达，这让我们可以从繁杂的领域模型里暂时解脱出来看业务本身的上下文关系。所以事件驱动本身也代表着业务流程的本身，只是做了一些精简，这像是一种假象暂时让我们觉得事件驱动就是可以直面业务的，可以方便容易建模的。

2.2 事件溯源

从上面的事件驱动分析来看我们似乎是顺着业务的走向去分析事件做领域建模的，但是有大佬已经关注到了在某些领域为需要去关注很早之前的事件，并当作一个历史时间线一样的东西去表达它，所以产生了一种特别的领域驱动设计模式就是事件溯源模式。比如我们的操作日志，单据变更记录，比如关注点赞,qps,tps等等。我们需要关注每个事件产生之后如何跟历史事件关联来做一些特别的业务需求。

2.3 建模产物

上面看到了两种事件建模的场景，这里我们分析一下基于事件驱动或者事件溯源建模的产物是什么，是不是我们建模完成之后就不再关注事件模型本身了，毕竟我们的业务模型才是更重要的对吧。比如看一位美女大多数人都在看这位美女的身材多好多棒，但是大家可能更喜欢看她在走路，在跳舞，在向你微笑的时候她的整体美。毕竟如果把除了眼睛以外的部位全部挡去你也不知道她是不是在愤怒的瞪着你。

那么扯了这么多，我们是不是需要把事件本身和业务模型本身区分开来或者就当成一类产物呢？我觉得不是，在不同领域不同业务需求系统里对事件的关注点可能没有模型本身多，比如我最近在准备做基于COLA-DDD的auth平台后端DDDinAction工程，我真想不到这个权限会有哪些事件供我去驱动权限本身的变化，可能就是思维或者经验主义让我想不到有哪些太多的事件来帮我梳理权限业务流程中的关键节点。所以在这里我可能无法用事件驱动来帮我构建权限模型了。那么我能完全不关注事件吗，也不是。只是我只能从模型上看到少量的事件。或许我需要跟权限领域的专家单独聊聊了。

那我们看一下另外的例子，今年在DDDChina峰会上有位亚马逊的专家开发者分享了混沌工程实践，重点提到了事件和事件溯源等等。说到了一个常见的场景，就是如何去捕捉异常事件，做异常报警，同时控制异常危险范围。那么对于这个领域而言很明显，不同的异常的发生就是一个事件，一个技术监控领域的异常事件，我们需要有一定的机制去捕获它，了解它，防御它。那这个事件这么看来肯定是已经发生过的，对吧。所以做混沌工程就是说我要主动构建一个预期的异常事件，来看看整个业务服务集群有什么样的反应，能不能自己扛过来。

从上面可以看到，事件驱动能解决领域建模问题吗？我觉得不全能。

2.4 模型优化

从上面的分析可以看到基于事件驱动的领域建模其实具有两类，一类是基于事件驱动寻找主要的业务模型，另一类是基于事件驱动来构建事件流本身。那么当我们识别到事件并构建完善领域模型的时候，我们需要对事件背后的模型进行完善，并根据识别出的上下文，聚合根进行事件流程串联。对于事件流本身，可能大部分场景事件是相对离散的，没有绝对的关联关系，所以这里我们可以指关注事件本身的数据内容，对于需要的信息或者可以砍掉的信息会很容易进行优化。

三、总结

这里我们简单总结一下事件驱动为什么在领域建模中会受到众多大佬青睐。

3.1 事件驱动建模的可操作性

偏向工程师思维

搞技术的大佬更偏向于工程师思维，容易抓住业务流程中的核心主线，相对容易的识别业务流程中的关键事件，那么对于事件驱动建模而言就很容易，比较顺手。

事件具有因果关系

由什么操作引发什么事件，事件后续的操作是什么具有一定的线性关系，在某一角度看比较容易理解，在建模方面更容易聚焦到业务流程中。

事件可转换成消息

在分布式或者微服务中业务流程的交互会涉及到多个子系统，多个领域，所以同步有时候会变得很慢也不满足业务需求，在异步中消息是解耦合的关键。所以进行事件建模的时候如果跨多个业务领域或者多个业务服务的话，某些事件可以转换为消息，从而表达事件对其他领域的影响，间接表明系统间的上下文依赖流程。所以事件模型在实践落地的时候依然具有一定的作用。