2
命令在CQ [R] S模型中应该有多精细？
我正在考虑一个项目，我们基于WCF的SOA的迁移部分转移到服务总线模型（可能nServiceBus），并使用一些基本的发布-订阅实现命令查询分离。 我对SOA甚至服务总线模型都不陌生，但我承认直到最近，我的“分离”概念还仅限于常规数据库镜像和复制。尽管如此，我还是被这个想法所吸引，因为它似乎提供了最终一致的系统的所有好处，同时又避免了许多明显的缺点（最明显的是缺乏适当的交易支持）。 我从Udi Dahan那里读了很多关于该主题的书，他基本上是 ESB体系结构的专家（至少在Microsoft世界中是这样），但是他说的一件事确实让我感到困惑： 当我们获得更大的实体并在其上具有更多字段时，我们也将有更多的参与者与这些相同的实体一起工作，并且在任何给定时间某些事物触及它们的某些属性的可能性更高，从而增加了并发冲突的数量。 [...] CQRS的核心要素是重新考虑用户界面的设计，以使我们能够掌握用户的意图，因此，使客户成为首选对象对于用户而言是与指示客户已搬家或已获得客户不同的工作单元。已婚。如上所述，使用类似Excel的UI进行数据更改不会捕获意图。 -Udi Dahan，澄清了CQRS 从引文中描述的角度来看，很难与这种逻辑争论。但这似乎与SOA背道而驰。SOA（实际上是一般的服务）应该处理粗粒度的消息，以便最大程度地减少网络震颤，这还有许多其他好处。 我认识到，当您拥有分布良好，消息队列良好且没有RPC负担的系统时，网络颤抖就不再是问题，但是完全消除该问题似乎并不明智。Udi几乎似乎在说，每个属性更改（即字段更新）都应该是它自己的命令，很难想象一个用户可能像传统上那样经常更新数百或数千个组合的实体和属性。网络服务。 给定良好的高度参数化查询，表值参数或对临时表的批量插入，SQL Server中的一次批处理更新可能花费一秒钟的时间；一次处理所有这些更新很慢，很慢，而且OLTP数据库硬件是所有扩展/扩展中最昂贵的。 有什么办法可以调和这些相互竞争的问题？我是否以错误的方式思考？这个问题在CQS / ESB领域是否有众所周知的解决方案？ 如果不是，那么如何确定命令中粒度的“正确级别”呢？是否有一些“标准”可以用作起点（类似于数据库中的3NF），并且仅在仔细分析表明潜在的显着性能优势时才偏离标准？ 或者，尽管各种专家表达了一些强烈的意见，这可能只是其中的一种吗？