在使用领域驱动设计实现 CQRS 时，我们将命令界面与查询界面分开。
我的理解是，在域级别，这显着降低了域模型中的复杂性(尤其是在使用事件源时)，因此您的读取模型将与您的写入模型不同。所以这看起来像是一个单独的域服务，用于您的读写有界上下文。
在应用层面，我们域的读写分离是否需要单独的应用服务？
在这件事上，我一直在扮演魔鬼的拥护者。我的想法是这可能有点矫枉过正，要求客户知道其中的区别。但后来我想到了消费网络服务可能会如何使用它。一般情况下，它会发出读取请求和写入请求，这意味着它已经知道了。
我看到了更清洁的应用程序服务的好处。
最佳答案
真正的值(value)是拥有一个正确分离的读取和域模型。他们做根本不同的事情。并且通常具有非常不同的形状。例如，读取模型完全有可能包含来自不同域对象的数据的混合。
当您考虑如何使用它们以及应用程序中的功能时，您就会开始意识到分离的必要性。这里的经典示例是考虑与典型应用程序中的读取相比的写入次数。读取的数量远远超过写入的数量。通过保持差异，您可以针对各自的角色优化每一方。
要记住的另一个方面是“帖子”将构成一个命令，而不是可能包含读取模型的 View 模型。如果使用 CQRS 方法，您需要调整查询和发布的方式。事实上，您可以获得一种更具描述性的语言，而不是简单地将 View 模型来回反射(reflect)到服务器。
如果您有兴趣，我有一篇博客文章，其中概述了典型 CQRS 架构的高级概述。你可以在这里找到它: A step by step overview of a typical CQRS application 。希望你觉得它有用。
最后一点。我们正在添加新功能，并发现分离非常有用。一侧的变化不会以与它们可能相同的方式影响另一侧。
关于domain-driven-design - 在领域驱动设计的 CQRS 实现中为命令/查询单独应用服务？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36598035/