CQRS - 围绕“获取或创建”的选项

Question

我正在使用CQRS模式将事物放在一起（没有事件来源，也没有DDD，但命令和查询之间存在明显区别）。

我正在尝试建模的操作是“获取或创建”，给定一组参数。正在创建（或获得）的项目实际上是唯一的通信链接ID。两方中的任何一方都可以说“在我和另一方之间获取或创建通信链接”并返回一个新的临时随机ID（这两者之间有效）。然后，他们可以使用该ID（PostMessage命令或GetRecentMessages查询）发送/接收消息。这个临时ID可以传递，但也可以集中无效，控制等。双方之间的不同会话应该单独记录。

我知道更典型的“insert-then-get-me-the-ID-back”由具有GUID参数的命令处理。但这似乎不适用于此，因为该项目可能已经存在..

我的选择，我相信：

1. 执行GetOrCreateCommsLink命令后跟GetActiveCommsLinkId查询，即命令，然后查询。感觉不对，因为命令通常是异步的（虽然目前为止不是我的简单原型），是否正确等待命令然后在我的服务层运行查询？
2. 运行GetExistingOrNewActiveCommsLinkId查询，该查询将返回现有会话ID，或创建并返回一个。感觉不对，因为它是一个肮脏的作弊，在查询中都是阅读和变异状态..
3. 不要在应用程序的这一部分使用CQRS
4. 让每个客户端使用自己的ID进行会话 - 来自每一方的NotifyCommsLinkIdentifier命令指定参数和它们自己的ID，该ID通过命令在内部链接到实际ID。然后在给定前面指定的标识符的情况下运行GetUnderlyingCommsLinkId查询，以在需要时显示ID。感觉不对，因为发明这个额外的概念似乎只是因为CQRS模式，而不是任何实际的域/业务需求

我想我的问题一般是如何处理潜在的get-then-act或act-then-get场景。我应该根据选项1在服务层中将它们链接在一起。

是否有标准方法或标准方法？

Answer 1

所以你说的是CQS，而不是CQRS。基本上，您正在尝试找到变通方法，以便严格地实现CQS模式，而这些模式自然可能并非真正的异步命令。

我的建议是：不要因为模式而尝试应用模式，但因为它有意义。你的情况有意义吗？有什么好处？请记住，您不是亚马逊。你真的需要吗？

那就是说，我通常做的不是纯粹的方式，而是允许命令返回一个简单的ID，如果需要的话。这将使您的架构更简单;并且你仍然将命令与查询分开，这对我来说是最重要的优势。