2013-04-09 81 views
3

我开始使用CQRS,我发现我的事件类定义几乎匹配我的命令定义1。除了显而易见的代码重复,我试图找出我做错了。肯定有一些情况下,事件不符合命令....但不是很多。CQRS匹配事件和命令

采取简单的CUD场景:

命令类:

  • CreatePost
  • UpdatePost
  • DeletePost

事件类:

  • CreatedPost
  • UpdatedPost
  • DeletedPost

对此有何建议?

我正在使用事件存储,如果这有什么区别。

谢谢。

+0

你可以扩大这个*我想弄清楚我做错了什么。*你为什么认为有什么问题? – 2013-04-23 05:25:47

+1

因为它看起来像我完全重复代码没有什么好处。 – Jeff 2013-04-23 14:48:07

回答

5

您通常不会在CRUD场景中使用CQRS。有更简单的工具和模式来创建CRUDy应用程序。

CQRS为行为丰富的场景带来很多好处,其中动词不是创建,读取,更新,删除,但更像真实的行为。像PromoteEmployeeBlacklistVendor

一旦你开始建模一个行为丰富的域,可能还有很多核心命令/事件 - 这不是一件坏事 - 但是你也会发现命令和结果事件可能会非常不同大小(包含数据)和数量。

+0

我使用上述作为一个简单的例子。上面的CUD操作是包含更复杂命令的更大有界上下文的一部分。即使在那里,我发现我的活动大部分都是我的命令的重复。 – Jeff 2013-04-09 12:57:28

+3

@杰夫仍然不是一件坏事。你想要什么事情发生(命令),然后发生(事件)。在很多情况下,这种重复只是现实的反映。并且在这种情况下引入诸如重用之类的东西在这种情况下没有任何意义,因为它会与您的系统各部分分离的想法相矛盾。 – 2013-04-09 13:09:00

+0

@Jeff很不幸,你选择了CRUD作为例子,这实际上使谈话失败了。 – 2014-09-04 18:32:40

1

为了给Dennis Traub的答案增加一点点,CQRS扩展了你如何将你的代码构造到规范的领域,即UI如何工作。并不是所有的UI都是CQRS友好的;你需要更多沿着Task-based-UI's rather than CRUD-y UI's的路线。

从CRUD-y UI开始,您可能会发现自己在应用CQRS时感到沮丧。

+1

非常好的一点 – 2014-09-05 07:58:16