当使用领域驱动设计实现 CQRS 时，我们将命令接口与查询接口分开。
我的理解是，在域级别，这会显着降低域模型中的复杂性（尤其是在使用事件源时），因为您的读取模型将与写入模型不同。因此，这看起来像是一个用于读写有界上下文的单独域服务。
在应用层面，我们是否需要一个单独的应用服务来实现我们域的读写分离？
我在这件事上一直唱反调。我的想法是，要求客户知道其中的区别可能有点矫枉过正。但随后我会考虑消费 Web 服务如何使用它。一般来说，它会发出阅读请求和写入请求，这意味着它已经知道了。
我看到了更清洁的应用程序服务的好处。
真正的价值在于拥有正确分离的读取和域模型。他们做的事情根本不同。并且通常具有非常不同的形状。例如，读取模型完全有可能包含来自不同域对象的数据的混合体。
当您思考它们的使用方式以及应用程序中的功能方式时，您就会开始意识到分离的必要性。这里的经典示例是考虑典型应用程序中写入次数与读取次数的比较。读取的数量远远超过写入的数量。通过保持差异，您可以优化每一方各自的角色。
要记住的另一个方面是“帖子”将构成命令而不是可能包含读取模型的视图模型。如果使用 CQRS 方法，您需要调整查询和发布的方式。事实上，您可以实现更具描述性的语言，而不是简单地将视图模型来回反映到服务器。
如果您感兴趣，我有一篇博客文章概述了典型 CQRS 架构的高级概述。您可以在这里找到它：典型 CQRS 应用程序的逐步概述。希望您觉得它有用。
最后一点。我们正在添加新功能，并发现分离非常有帮助。一侧的变化不会以同样的方式影响另一侧。