我正在学习微服务，并且正在学习使用流行的领域驱动设计战术模式和 CQRS 来实现它们。对于我的第一个项目，我尝试创建一个简单的电子商务设置，因为有关该主题的每个教程似乎都是电子商务教程。
我目前没有使用事件源，只是使用没有事件的 SQL 数据库。
在思考了这个领域一段时间后，我得出的结论是拥有两个微服务（还有许多其他微服务），其中一个处理卖家的用例，例如将产品添加到其列表、更新其信息等的端点，另一个处理卖家的用例。微服务，用于处理具有端点的客户通过店面对产品的查询，以使用不同的排序和过滤选项获取产品。
现在我想到的流程是
我假设目录服务将是基于查询的服务，并且它不需要任何命令，因为这里不会有太多业务逻辑处理（我假设命令是用户的方式） API 向域发送请求以执行某些操作）。
但是我不完全确定我是否致力于这种思路或者它是否是正确的方法，并且我想知道我是否应该使用命令 -> 域层 -> 存储库流将产品保存到它的数据库，或者直接执行 SQL 命令以从 IntegrationEventHandler 保存它们，或者是否有更好的方法。 在以查询为中心的微服务中保存内容是否应该只是简单地保存到数据库，而不是使用命令之类的复杂流程？
我看到的另一件事是，在自己的数据库中拥有可查询数据的 MaterializedViews 是件好事，这样就可以对领域对象进行建模，而不必担心查询结果如何以及查询需要哪些数据，它们还可以跨越来自多个服务，并且可以以提高性能的方式存储它们。
我假设这些查询将位于它们自己的微服务中，并附加有自己的数据库。使用与域对象类似的数据的简单查询只是同一微服务的一部分，但微服务应该在查询和命令之间有明确的分离。这个思路是正确的还是我在某个地方犯了错误？
我很想了解您对这些问题的看法，这样我就可以真正致力于一种不怀疑自己的思维方式，说实话，学习这些真的让人不知所措:)。
谢谢你。
没有关于微服务应该做什么的规则。微服务的定义表明它如何做它所做的事情、它的边界是什么、它如何与其他服务交互等。
有时，由于查询的性能和复杂性，在线购物产品浏览场景变得更加重要。为了管理这种情况，您可以将这些场景分隔在一个称为微服务的独立边界中。为此，我们创建一个独立的数据存储并设计一个高性能结构来存储数据。
CQRS 出现并建议我们将有界上下文的写入模型与读取模型分开。从这个意义上说，我们将拥有相同有界上下文的两个微服务。其中一个用于浏览场景，另一个用于处理更改数据的命令。
微服务应该在查询和查询之间有明确的分离 命令。
这句话我觉得还是把“微服务”改成“限界上下文”比较好。有界上下文可以有两个微服务来处理其命令和查询（一个微服务通常可能包含两个有界上下文，这里没有限制）。我认为您有一个名为“CatalogueBoundedContext”的有界上下文和两个名为“CatalogueManagement”和 CatalogueBrowsing”的微服务（名称可能不准确，它们只是为您绘制了一张图片）。
我是否应该使用命令 -> 域层 -> 存储库 流到这里将产品保存到数据库中，
在查询方面，您可以应用任何您想要的应用程序架构，但请记住写入模型上已经发生的业务不变量检查、验证和处理。所以你不必担心他们。您只需担心如何将写入模型输出消息应用到读取模型上（通常 CRUD 基本操作就足够了）。