如何为事件溯源项目规划技术堆栈 -Keith Mifsud


在与开发人员,工程师和软件开发实验室就新的Event Sourcing项目进行培训或咨询时,我遇到的最常见问题是我们如何以及从何处开始。
这个问题非常有意义。我记得在实践中试图绕过面向对象编程(不是我在学校学到的废话),更不用说理解领域驱动设计了!
大约十年前,我为当时最大的客户之一:工业制冷和空调系统的制造商,批发商和分销商,建立了一个相对复杂的在线和离线销售和物流系统。
在该项目的三个月中,我的团队有三名软件工程师:两名后端Web开发人员和一名前端开发人员。我们取得了卓越的进步。我们正在使用DDD模型和Laravel作为应用程序框架来构建此系统。很好,我们富有成效。
我选择PHP作为主要的后端编程语言。但是,我有信心,规划因素适用于您要用于Event Sourcing项目的任何编程语言。在本文中,我将概述规划基础结构和两者之间的应用粘合的注意事项。

事件存储数据库
事件存储最关键的持久性存储是事件存储数据库。如您所知,您可以使用几种不同的数据库引擎来运行事件存储。在这篇文章中,我将不比较这些引擎中的任何一个,因为我们需要知道的是我们需要一个附加的优化数据库。
鉴于事件源的不变性,我们当然不需要更新任何持久事件。我们也不需要运行任何复杂的读取查询。正如我将在以后的文章中提到的那样,事件存储实现将查询由聚合的UUID(通用唯一标识符)标识的持久事件。那是一个非常简单的查询。
我也不鼓励在NoSQL数据库上实现您的事件存储。
无论如何,我都选择在MySQL   数据库上实现事件存储  。我发现  PostgreSQL   对于Event Store的实现也非常有用,并且我已经使用了几次。
这样,我就对清单应用程序的基础结构做出了第一个决定。我将使用MySQL来保留事件。但是,我将通过使用存储库模式将所有模型的代码与该决策分开。因此,如果将来改变主意,则只需要更改实现并以某种方式迁移数据即可。

读取模型数据库
尽管我以前使用MySQL来保持读取模型的持久性,但是我为读取模型实现NoSQL数据库的次数越多,我越喜欢NoSQL给应用程序提供的灵活性。
我将  MongoDB   用作该系统的读取模型的数据库,除了我在日常工作中经常使用它外,没有其他特殊原因,因此我对此非常满意。

应用框架​​​​​​​
我需要一个应用程序框架吗?可以说,我没有。我需要一个可由用户访问的应用程序层,例如用户界面。但是,我在应用程序层中还需要一些其他基本组件。这些顺序不分先后:
-能够解析我的依赖项的具体实现。
-可以轻松地将所有具体实现与新实现互换的功能。
-传入请求和模型之间的反腐败层。
-客户端和用户的某种形式的身份和身份验证。
-能够使用环境变量隔离可配置选项。
可能还有其他一些要求,例如引导整个过程
然,我们可以使用一堆解耦的组件,它们可以一起满足所有要求。我以前做过,甚至成功过。为什么不继续使用Laravel 这样的框架呢  ?

API访问​​​​​​​
我还打算将GraphQL用作API的查询语言。我发现  GraphQL   和无模式的读取模型是完美的选择。但是,这很可能导致使用更少的Laravel HTTP层,因为(例如)GraphQL类型系统可以充当应用程序层的反腐败层,而不是Laravel的请求对象。使用此API还意味着我可能需要自己开发GraphQL实现,因为(当前和AFAIK)用于GrapghQL和Laravel的所有当前库都使用Eloquent作为类型系统。我不会将Eloquent用于读取模型,因为它克服了我非常喜欢的无模式优势。

更多php代码细节点击标题参考原文,本文代码:Git存储库 ​​​​​​​