domain-driven-design - CQRS 对我的域是否正确？

Question

我正在建模一个文件，它是视频需求系统的一部分。将文件想象成 Windows 资源管理器，多个用户可以在其中创建文件夹、上传视频、重组文件夹等。 有业务规则(权限)确定是否允许用户执行任务(即重命名文件夹、移动文件夹、查看文件夹等) )。

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

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

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

这让我想到，CQRS 是否适合我试图解决的问题？如果是这样，我的聚合可能是错误的吗？

Answer 1

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

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

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

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

这代表了恕我直言，领域驱动设计中最重要的概念，即专注于核心领域