是否有一个成熟的，易于使用的CQRS框架，它不是特定于Azure的，也不是过时的，或者没有被很好的采用？

Question

我一直在研究用CQRS实现.net的问题。我到目前为止所看到的一切，要么是自己做的，要么是特定的，过时的(我认为)，或者没有被很好地采纳。

问题：

• Scritchy不是很好的采纳
• NCQRS -看起来有点老了吗？它还需要一个DIY-ish设置-意思是，你需要自己创建几个项目(虽然没有那么糟糕)。
• https://github.com/gregoryyoung/m-r -更像是一个理论演示而不是一个生产框架
• LOKAD.CQRS -主要是天青特有的
• https://github.com/MarkNijhof/Fohjin --再说一遍，更像是一个演示而不是框架。

我在做一个新项目。它将托管在AppHarbor中。我想使用CQRS方法。我更喜欢使用一个很棒的框架，而不是自己编写/复制它。

Answer 1

(免责声明:我是“Scritchy”的作者)

我不能为其他框架说话，但在我的例子中，Scritchy仅仅是因为我想提供一个快速易用的工具来编写CQRS应用程序，同时也减轻了反复编写类似命令处理程序的一些负担。

正如专家们所说: CQRS在它最基本的表示中非常简单，所以它实际上不需要一个框架。

但是，由于我个人经常使用CQRS方法，而且我讨厌一遍又一遍地编写相同的样板代码，所以我决定为它编写一个自以为是的框架(想想RoR for CQRS)。

Scritchy是一种非常实用和固执己见的CQRS方法(更喜欢约定而不是配置)，但它的设计方式是每个组件都应该很容易被其他组件替换.(也就是说，很容易为您的ARs替换基类是唯一的依赖项)。

由于Scritchy已经开发了很短的时间- -尽管它能够很好地满足我的需要，但它并不像大多数其他框架那样被采用。

社区中很多人似乎都赞同的一个框架是乔纳森·奥利弗的活动商店，这并不是S所说的具体的CQRS框架，但他确实在您的CQRS应用程序中提供了可以使用的一些公共域对象。

我的建议是:选择一个，建立基本的基础设施，然后开始。CQRS中最困难的部分通常不是在基础设施中，而是在领域(或者至少应该是;)