事件溯源和清洁架构——领域模型是否需要处理事件？答案

【问题标题】：Event Sourcing and Clean Architecture - does domain model need to handle events?事件溯源和清洁架构——领域模型是否需要处理事件？
【发布时间】：2021-12-23 01:31:30
【问题描述】：

我仍在学习清洁架构，现在我正在尝试在项目中实现事件溯源。我有 2 个项目，一个包含命令和事件，一个是域模型。根据干净架构的定义，域模型是一切的中心。一切都参考他。但是，我发现的所有示例都表明域模型对每个事件都有 Apply 方法。

我需要在域模型中这样做吗？还是有其他方式？

在代码中的某些地方，我需要从类似这样的事件中重建域模型：

public void Load(events){
foreach(var event in events)
{
   Apply(event);
}}

这应该在领域模型类中，例如Apply 方法。 Apply 方法改变领域模型的内部状态。

【问题讨论】：

您能否提供一些代码示例，让我们更容易想象？干杯
这个范围很广。显然，在编程中有成千上万种方法可以做任何事情。您显然正在阅读一本书或从某个来源学习，并假设我们都知道您在说什么。请edit您的问题为您的问题提供更多背景信息。
“但是，我发现的所有示例都表明域模型对每个事件都有 Apply 方法。” - 为什么会有“但是”？您还会如何将更改应用到您的域模型？
啊，好的。我认为这个例子实际上有助于理解你的误解。请参阅（域）模型应该保持域的当前状态。如果您启动系统，它没有状态或空白状态，如果您愿意的话。所以你需要给它一个种子来预热它，然后对该状态执行所有历史更改，直到你拥有当前状态。
@milandjukic88 这不仅“可以”，而且您需要拥有这些。否则，您将无法执行称为“重放”的操作。

标签： c# domain-driven-design event-sourcing clean-architecture

【解决方案1】：

我发现的所有示例都表明域模型对每个事件都有 Apply 方法。我需要在域模型中这样做吗？

您不必“必须”这样做，但这可能是名词王国设计中的一个结果。由于领域驱动设计 (Java) 和事件溯源 (C#) 的大部分早期开发都发生在名词王国，因此这些示例倾向于共享这些模式。

使用Apply 模式，您会看到两种不同想法的结果。

第一，所有事件源模型都具有相同的底层数据结构的想法（事实是事件的历史），因此我们应该为所有模型使用一个通用的通用实现。

第二，我们在数据模型中缓存的信息（也就是模型对象的“属性”）应该看起来“相同”，无论我们是查看处理命令的原始对象还是查看副本从历史中加载的那个模型。

因此，出现了一种模式，即模型倾向于“继承”某个基类，该基类拥有一个事件历史记录和一个用于协调对历史记录和模型自身内部缓存的更改的 api，并且模型上的命令处理程序通过首先计算应该发生哪些更改（事件），然后应用这些更改使用与重新加载事件历史记录时相同的代码路径。

【讨论】：

值得注意的是，在动词王国（又名“函数式编程”）中，事件只不过是将状态（alt.“模型对象”）映射到状态/“模型”的函数目的”;那个王国无处不在的语言可能是指“将事件应用于一个国家”（如果没有别的，这要归功于 Lisp/Scheme 的历史）。
还有一个不那么荒谬的论点，即大部分 DDD/ES 和相关实践只是将函数式编程走私到“企业”中......