aggregate - DDD、事件溯源和聚合状态的形状

Question

我很难理解state应用该实体的事件与该实体数据的投影得出的形状。

聚合的状态是否仅用于确定是否可以成功应用命令？还是应该以其他方式使用该状态？

一个例子 - 我有一个标准博客文章的 Post 实体。我可能有像postCreated, postPublished,postUnpublished等这样的事件。对于我将保留在我的阅读表中的预测，我需要一个基本的预测posts（这将包括所有帖子，无论状态如何，都有很多细节）以及published_posts投影（仅代表当前发布的仅包含渲染所需信息的帖子。

在上述情况下，我的聚合状态是否仅用于确定，例如，是否可以发布或未发布帖子等？如果是这种情况，我在聚合中的状态形状是否纯粹由这些验证所需的内容定义？例如，在我的基础post投影中，我想要列出所有对帖子进行更改的用户。在对聚合/命令的验证方面，我不太关心进行了更改的用户列表。这是否意味着此列表不应该是我的汇总中我的状态的一部分？

标签： aggregatedomain-driven-designcqrsevent-sourcing

Answer 1

TL；DR：是的 - 将聚合中的“状态”限制为您选择缓存以支持数据更改的数据。

---

在我的聚合中，我区分了两种不同的想法：

• 历史，也就是描述聚合生命周期变化的事件序列
• 缓存，也就是我们藏起来的数据值，因为每次查询事件历史都很糟糕。

缓存我们永远不会使用的结果并没有太多价值。

CQRS 的基本教训之一是我们不需要到处都使用聚合

AGGREGATE 是一组关联对象，我们将其视为一个单元，用于数据更改。——埃文斯，2003

如果我们不更改数据，那么我们可以安全地直接使用数据的不可变副本。