为什么要从 CRUD 转向事件源架构？( 二 ) 作者｜SavanKharod译者

为了更好地理解事件源架构，让我们以Gary的银行账户为例。假设Gary的账户里有2400美元。他用499美元购买了PS5游戏机。电子商务网站为他提供了49美元的返现。在这种情况下，事件源表会是这样的：

文章图片
通过追踪一段时间内的取款和存款，可以计算出他目前的账户余额为1950美元。这种状态的复原和事件的回放被称为重放。
我们可以把事件源视为客户活动的日志。
如果我们从电子商务平台的角度来看Gary的活动，添加游戏机是第一个事件，添加控制器是第二个事件，以此类推。事实上，结账过程也是一个独立的事件。如果Gary不小心在购物车中添加了三个控制器（例如，事件1、2和3），然后他又删除了一个，那么删除也是一个独立的事件：事件4！
采用事件源架构的好处
从对事件源的基本理解来看，它似乎是一个更好更完善的替代方案，克服了CRUD的缺点。为了进一步说明这一点，让我们看一下事件源已被证明了的优势。
事件源遵循事件驱动的架构，方便在状态变化时可靠地发布事件。
它通过持久化事件而不是领域对象，克服了CRUD中出现的对象-关系阻抗不匹配问题。
它维护了一系列事件的记录，可以在只限追加的状态下进行操作。通过消除状态跟踪和实体关系的需求，编写读写数据库的事件源代码更容易。
由于保留了实体如何到达当前事件的日志，所以事件源保证了审计数据和交易数据的一致性，因为它们是一样的。此外，它也是一个很好的故障保险，因为数据可以从事件日志中重建。
所有的事件只是被追加到现有的数据库中，并且更新和删除功能已被去掉，事件源架构只关注写入，这提高了其性能。
事件源允许对事件流进行分析，这有助于企业从中获取关键信息。他们可以获得所有系统活动的顶层视图，而不会使写入功能复杂化。
遵循事件源模型的架构更容易测试和调试，因为在引入命令和事件之前，可以对其进行模拟测试。此外，事件日志还可以作为一个很好的调试活动记录，如果发现问题，可以在受控环境中重放事件日志，以了解导致异常的原因。
它可以存储任何类型的信息，任何消费者只要获得授权，就可以访问这些信息。它允许通过时间查询实体在任何时候的状态。因此，它非常灵活。
与单体架构相比，事件源应用程序更容易迁移，因为它们遵循基于微服务的架构。之所以如此，是因为参与事件交换的业务实体之间是松耦合的。
结语
随着越来越多的应用程序需要以有序和异步的方式传递实时数据，企业对事件源的需求也越来越大。此外，它也是在网络规模上消费和管理应用程序日志数据的绝佳方法。在这种情况下，事件源成了一个唯一的事实来源，提高了应用程序的可靠性。
那么，你所在的企业打算何时从CRUD迁移到事件源架构？
https://dzone.com/articles/why-do-you-need-to-move-from-crud-to-event-sourcin?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJhY2Nlc3NfcmVzb3VyY2UiLCJleHAiOjE2NDIxNDU1NzUsImciOiJLOEdoZGtjdlF2SHkzeDhwIiwiaWF0IjoxNjQyMTQ1Mjc1LCJ1c2VySWQiOjI0MzYwNzkwfQ.yHCE5wZnN1J6Gb4eKsvz-XrB82uZpWtFq3OmKmoHzbg