domain-driven-design - 指导何时坚持使用 CRUD ORM 或切换到 DDD 事件存储的规则

Question

我已经看到 ORM 使用一个工作单元在一个步骤中提交多个存储库。

我还看到了 DDD 和通过存储库保存的聚合根的使用，当使用事件存储时，持久性在概念上变得非常容易理解。

我总是需要编写数据访问代码，虽然我熟悉 ORM，但我是域驱动设计和事件溯源的新手——事件溯源很棒，但确实有很多基础设施。

最终，我想要一些规则来帮助决定 DDD+ES 在什么时候（代码大小、数据库实体的数量）变得值得在 CRUD 系统上付出额外的努力。

为了帮助决定我的问题如下：

1. 我还没有看到聚合根合并到一个工作单元中，这可以避免吗？如果是这样，这会导致什么问题？

2. 在 DDD 中，客户实体可能具有嵌入其中的地址和电话（值对象），而在 ORM 中，有一个包含客户、电话和地址存储库的工作单元。解释和理解这些不同方法的最佳方式是什么？

3. ORM 可以使用多个不同的工作单元（每个都引用相关和相关的存储库/表）来表示聚合根吗？

4. 从我的域到 ORM 的阻抗不匹配需要注意哪些痛苦/警告信号，此时我们可以考虑切换到事件存储？

Answer 1

1. 聚合定义了一致性边界。在 NoSQL 数据库中，通常不可能在每个事务中提交多个实体。因此，在使用 NoSQL 的 DDD 中，希望在一个工作单元中只有一个聚合，而对手头聚合外部实体的更新以最终一致的方式交付。

2. 如果地址和电话是值对象，那么它们不应该有存储库。在 ORM 中，它们将被映射为父实体的组件，而不是单独的映射。

3. 我不确定你会以这种方式实现什么？

4. 自然导致事件溯源的一个痛点是需要将所有状态更改保存在一个聚合中。此外，事件溯源和领域事件的概念通常提供了一种不同的领域建模方法，专注于行为而不是状态。当保留所有状态更改具有潜在的商业价值时，我会考虑使用 ES。如果您愿意进行初始基础设施投资，ES 可以通过避免 ORM 疯狂在许多方面变得更简单。将 CRUD 视为只有 4 种事件类型，甚至 2 种（读取、更新）的事件源。除了最基本的领域之外，希望有更多的上下文，而不是导致您进入 ES 的数据更改。