DDD\ES\CQRS 中应用程序的 CRUD 部分答案

【问题标题】：CRUD part of app in DDD\ES\CQRSDDD\ES\CQRS 中应用程序的 CRUD 部分
【发布时间】：2013-02-20 13:58:27
【问题描述】：

我想在我的项目中使用 DDD\CQRS\ES。我刚开始使用它，所以我没有很多经验。我知道现有的核心域、支持域和 CRUD 域。我的核心域引用了 CRUD 数据。比如Order里面有很多业务规则，但是里面包含了Delivery Company，receipt point等基本信息。

这些信息由管理员管理。我认为我应该使用 crud 方法，但是当我需要回滚事件时会发生什么？

系统将存储混合数据 - 从事件源恢复和从应用程序的 crud 部分实际恢复。我最终会得到不一致的数据。例如，订单可能由不存在的公司维护（该公司在交付包裹时被管理员删除，但回滚后订单仍处于活动状态）在每个项目中都是 CRUD 数据的一部分，那么您如何处理这个问题？我应该存储公司活动吗？

另外，当我添加新订单时，我应该通过事件发送公司名称和 ID，因为当我重建我的 ReadStore 时，数据库中可能没有公司，所以我无法从存储库中获取 companyName

PS。你知道任何可以处理简单 CRUD 操作的 CRUD 框架吗？

PS.2 你知道在 ES\CQRS 方法中包含应用程序的 CRUD 部分的任何示例开源项目吗？

好的。也许我描述得太复杂了。我只想知道：

如何实现应用程序的最简单部分（糟糕的业务逻辑 - 主要是 CRUD 操作）当我将我的核心域存储在事件存储，我希望能够恢复以前的状态我的核心域
是否应该将 crud 操作也存储在事件存储中？
回滚事件存储后如何提供一致的数据？
您推荐哪种 CRUD 框架用于 Java 应用程序？

【问题讨论】：

标签： domain-driven-design cqrs event-sourcing

【解决方案1】：

我认为这是处理 DDD 时的常见问题，尤其是处理 ES 时。这听起来可能很简单，但您需要寻找的是域中的有界上下文。事实证明，这种有界上下文很好地映射到 SOA 的服务上。现在，当您使用 SOA 时，您会意识到并非所有服务（SOA 中的服务作为 S 而不是 web/windows 服务中的服务）都需要以相同的方式实现。

根据我的经验，您总是会有一些服务主要处理 CRUD 操作和很少的业务逻辑，通常由管理员/特殊用户使用的应用程序使用。这些服务可以而且应该以尽可能少的努力实现，无需 CQRS 和 ES，也不会使它们过于复杂。只要确保他们在发生某些事情时发布相关消息。

Udi Dahan 也有一些关于 SOA 和 SOA 含义的非常好的视频：Avoid a failed SOA 和 Udi on SOA

我意识到这实际上并没有回答您问题的所有细节，但我希望它能为您指明正确的方向。

【讨论】：

【解决方案2】：

为什么不简单地将 CRUD 部分视为仅附加（如果必须的话，可以允许更新）或将足够的数据复制到事件中以不丢失重要数据？

【讨论】：

【解决方案3】：

我不知道你到底想问什么，但如果它涉及 DDD 和 CRUD 操作，Cocktail framework 可能会帮助你，尽管我自己没有尝试过。

【讨论】：