CQRS对我的域名是否正确？

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

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

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

我更喜欢某种交易处理移动（两个聚合上的改变）在一起，如果失败，至少我不需要撤消移动的第一部分或提出事件的第一部分。

这让我感到，是CQRS正确的问题，我想解决？如果是这样的话，我的聚合是错误的？

来源

2012-06-23 JD.

在DDD中，聚合应代表事务边界。需要多个集合参与的交易往往表明要么对模型进行细化，要么对交易要求进行审查，或者对两者都进行审查。

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

另一方面，你是否真的需要重新创建包含文件的文件夹等分层结构？据我所知，这已经是一段时间以来解决的问题。也许在再次正式确定特定领域时没有固有的优势。（1）域非常复杂，（2）对域进行建模将使软件具有与类似应用程序相比的真实（例如竞争性）优势。使用DDD模式的域建模在有界的上下文中最有意义。如果特定的有限上下文相当简单并且/或者重构不会带来真正的好处，那么最好使用最简单的解决方案。

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

来源

2012-06-23 13:09:07

谢谢您的答复。当你说“你真的需要重新创建分层结构......”时，你能详细说明一下吗？我有权限的概念和一些其他规则，如文件和文件夹不能混合（即文件夹必须包含其他文件夹或只是文件）。将来我们有文件快捷方式的概念（引用计数）。所有这些对我来说似乎都是域名，或者我认为是业务层。我对DDD很新，在这个阶段，我没有在我的域中引发持久性或事件。当读数增加时，我认为这是CSQR的帮助。 –

听起来像一个文件系统给我。我问的是，你真的需要重新发明一个已经存在多年的概念吗？你的模型会引入什么新的东西，这样你的新建模应用程序将比任何现有的文件系统都有明显的优势。基本上DDD是较少的软件分析和更多的业务分析。 DDD是关于域的形式化，通常在域已经被广泛形式化时通常不是必需的。长话短说：不要重新发明轮子。 –

对不起，我低估了你的答案。 1）它没有提供任何价值 - 我相信，OP在询问是否在技术上可行/合理的情况下，根据他们正在努力的使用情况建模他们的软件DDD方式。那么，你知道如何模拟DDD方式吗？2）“关注核心领域”是关于优先考虑你花费你的时间和精力 - 而不是软件是否存在。 3）“基本上DDD不是软件分析，而是更多的业务分析。” - 我相信，这与埃文斯在他的书的第一章中所写的相矛盾。 4）光顾你评论的语气。 – Nik

CQRS对我的域名是否正确？

回答

相关问题