事件源（事件源，事件日志记录，事件生成）是一种强大的体系结构模式，其中，对应用程序状态所做的所有更改均按发生的顺序保存。这些记录既可以用作获取当前状态的来源，也可以作为应用程序生命周期中所发生事件的审核记录。事件源有助于分散数据的更改和读取。此体系结构可很好地扩展，适用于已经进行事件处理或要迁移到这种体系结构的系统。
什么是事件来源
领域专家通常将其系统描述为实体的集合，实体是用于存储状态和事件的容器，这些状态和事件反映了由于在各种业务流程中处理输入数据而导致的实体变化。事件通常由来自用户，后台进程或与外部系统集成的命令触发。
本质上，事件源关注于与系统更改有关的事件。
许多架构模式都将实体视为主要概念。这些模板描述了如何保存它们，如何访问它们以及如何对其进行修改。在这种架构风格中，事件通常是“侧身”的：它们是实体变化的结果。
通常，这些体系结构基于诸如关系数据库或文档存储之类的实体存储。尽管事件可能会出现在这种体系结构中，但从本质上讲，它们不是主要概念，可以与事件相关的实体分离，也可以隐藏在业务逻辑层的后面。
事件源通过关注事件的实现来扭转这种方法：事件如何持久化以及如何用于获取实体状态。在这种情况下，数据库将包含在系统生存期内发生的所有事件的顺序日志。
下面是事件存储与实体存储的比较（下面将详细介绍）：
使用事件作为主要架构概念的事件源也是领域建模范例，可以更好地反映客户对系统的看法。设计强调事件和事件日志的系统具有以下好处：
- , « » .
- (command/query responsibility), .
- , , , .
Event Sourcing
让我们看一个带有银行帐户的简单示例。我们将有一个代表银行帐户的实体。为简单起见，我们将仅创建一个帐户，而无需使用帐号或任何其他方式识别它。该帐户将保留当前的资金余额。
该帐户有两个命令（命令）：存款（存款）和提款（提款）。这些命令将指示要存入或提取的金额。我们还将定义一个业务规则，以验证仅当请求的金额等于或小于当前帐户余额时才能处理提款命令。
使用这种方法，可以区分两个事件（事件）-“贷记帐户”和“借记帐户”。这些事件包含有关已存入或提取的金额的信息。这可以简化为一个具有正或负总和的事件，但是在此示例中，我们将其拆分。
下图显示了数据模型。
请注意，事件是“过去式”。它们指示在编写时系统中发生的情况，并且仅在命令处理成功时才保存。使用这种方法时，必须注意不要将命令与事件混淆。特别是如果他们彼此镜像。
命令序列可能如下所示：
1.存款{amount：100}-存款100
2.退出{金额：80}-退出80
3.退出{金额：50}-退出50
事件源的最简单实现需要一个事件日志，它只是一系列事件。处理上面的命令时，您会收到这样的日志。
由于请求的金额超出了可用余额，因此无法执行第三条命令。
为了获得当前余额，系统必须按事件发生的顺序处理或“生成”事件。对于我们的示例，它可能看起来像这样：
- 银行帐户{当前余额：0}（开始状态）
银行帐户{当前余额：0}（开始状态） - bank account { current balance: 100 } (processed: Account Credited, +100)
{ : 100 } (: , +100) - bank account { current balance: 20 } (processed: Account Debited, -80)
{ : 20 } (: , -80)
当前余额是通过处理直到当前时刻的所有事件来计算的。由于每个事件都有一个隐式时间戳，因此可以通过在所需时间段内处理所有事件来随时计算帐户状态。
这是事件采购的完整（尽管很简单）示例。在实际系统中，很可能需要扩展此示例。
可能需要保存命令序列以能够识别事件的发生方式，并创建单独的错误事件日志以记录未完成的命令，以进一步处理错误并维护成功和失败的完整历史记录。失败的团队。
随着时间的流逝，随着命令数量的增加，可能有必要保持当前帐户余额，以便在收到提款命令时，无需处理事件的完整列表来确定命令是否可以执行（即帐户是否有足够的资金）。这是派生存储的示例，与实体存储基本相同。
下面是实体存储在处理所有命令后如何查找我们的示例。
显然，与成熟的事件存储相比，这是一个非常原始的示例。这是许多开发人员仅使用实体存储的原因之一。在这种情况下，可以立即使用当前帐户余额，并且不需要处理所有历史事件。
但是，事件来源不排除实体存储。通常，实体存储也存在于Event Sourcing项目中。
第一部分结束。
