领域驱动设计中CQRS实现中命令/查询的独立应用服务？

Question

在使用域驱动设计实现CQRS时，我们将命令接口与查询接口分离开来。

我的理解是，在领域级别，这大大降低了复杂性(特别是在使用事件源时)，在域模型中，您的读取模型将与您的写模型不同。因此，这看起来像一个单独的域服务，为您的读写有界的上下文。

在应用程序级别上，我们是否需要单独的应用程序服务来实现域的读写分离？

在这件事上，我一直在挑拨离间。我的想法是，这可能是过火，要求客户知道区别。但是，我想到了消费的use服务可能如何使用它。一般来说，它会发出get的阅读请求和写文章的请求，这意味着它已经知道了。

我看到了清洁应用服务的好处。

Answer 1

真正的价值是有一个正确分开的读和域模型。他们做的事情完全不同。而且经常有非常不同的形状。例如，读取模型完全有可能包含来自不同域对象的数据组合。

当您考虑它们是如何使用的，以及应用程序中函数的使用方式时，您可以开始理解分离的必要性。这里的典型示例是考虑与典型应用程序中的读取相比的写入次数。读的数量远远超过了写的次数。通过保持差异，您可以为其各自的角色优化每一方。

要记住的另一个方面是，“post”将构成命令，而不是包含读取模型的视图模型。如果使用CQRS方法，则需要调整查询和发布的方式。实际上，您可以实现一种更具有描述性的语言，而不是简单地将视图模型来回反射到服务器。

如果您感兴趣，我有一篇博文，其中概述了典型的CQRS体系结构的高级概述。你可以在这里找到它：一个典型的CQRS应用程序的逐步概述。希望你觉得有用。

最后一点。我们正在添加新功能，发现分离非常有用。对一方的更改不会对另一方产生同样的影响。