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