CQRS 是否适合我的域？答案

【问题标题】：Is CQRS correct for my domain?CQRS 是否适合我的域？
【发布时间】：2012-06-23 11:22:00
【问题描述】：

我正在对作为视频需求系统一部分的存档进行建模。想想像 Windows 资源管理器这样的存档，其中多个用户可以创建文件夹、上传视频、重组文件夹等。有一些业务规则（权限）确定用户是否被允许执行任务（即重命名文件夹、移动文件夹、查看文件夹等)。

我已将每个文件夹建模为聚合根，将一个文件夹移动到另一个文件夹似乎会影响两个聚合根。

据我了解，我应该发送一个事件来修改另一个聚合。然而，我担心的是，如果第二个文件夹也被修改（比如从系统中删除或删除），那么我需要发送一个补偿命令来撤消第一个聚合更改。

我更喜欢某种同时处理移动（更改两个聚合）的事务，如果它失败，那么至少我不需要撤消移动的第一部分或引发事件的第一部分。

这让我想到，CQRS 是否适合我要解决的问题？如果是这样，是不是我的聚合有误？

【问题讨论】：

标签： domain-driven-design cqrs aggregateroot

【解决方案1】：

在 DDD 中，聚合应该代表事务边界。需要涉及多个聚合的交易通常表明应该改进模型，或审查交易要求，或两者兼而有之。

这是一个纯粹的 DDD 问题，独立于 CQRS 或任何其他架构模式。

另一方面，您真的需要重新设计分层结构，例如包含文件的文件夹吗？据我所知，这已经解决了很长一段时间的问题。也许再次将特定领域正式化并没有固有的优势。

使用 DDD 模式的域建模在有界上下文中最有意义，其中 (1) 域非常复杂，(2) 域建模将使您的软件相对于类似应用程序具有真正的（例如竞争）优势。如果特定的有界上下文相当简单和/或对其进行重构并没有带来很大的优势，那么最好使用最简单的解决方案。

这代表了领域驱动设计中最重要的概念，即关注核心领域

【讨论】：

感谢您的回复。当你说“你真的需要重新发明层次结构......”时，你能详细说明一下吗？我有权限的概念和一些其他规则，例如文件和文件夹不能混合（即文件夹必须包含其他文件夹或仅包含文件）。将来我们会有文件快捷方式的概念（引用计数）。在我看来，这一切都像是领域，或者我认为是业务层。我对 DDD 很陌生，在这个阶段，我的域中没有持久性或事件。当读取增加时，我认为这就是 CSQR 的帮助所在。
对我来说听起来像是一个文件系统。我要问的是，你真的需要重新发明一个已经存在多年的概念。您的模型是否会引入任何新的东西，以便您新建模的应用程序将比任何现有文件系统具有显着优势。基本上DDD是更少的软件分析，更多的业务分析。 DDD 是关于形式化领域的，当领域已经被广泛形式化时，通常不需要。长话短说：不要重新发明轮子。
对不起，我对你的回答投了反对票。 1）它没有提供任何价值——我相信，考虑到他们正在努力解决的用例，OP 正在询问以他们的软件 DDD 方式建模在技术上是否可行/合理。那么，您知道如何以 DDD 方式对其进行建模吗？ 2）“专注于核心领域”是关于优先考虑你花时间和精力做的事情——而不是关于软件是否应该存在。 3）“基本上DDD是更少的软件分析，更多的业务分析。” ——我相信，这与埃文斯在其书的第一章中所写的相矛盾。 4) 光顾您的评论。