cqrs web api mvc 或微服务

Question

我们正在努力构建一个新系统 (.Net)，它将把客户现有的 6 个系统合并为一个。目前的6个系统都有不同的数据库。在讨论 Web API 的设计时，客户询问我们是否可以遵循 CQRS 模式。我计划使用一个 Web API，将控制器分解为查询和命令，这些控制器又与服务（c# 类）一起工作，这些服务也被分解为查询和命令。

在一次会议中，另一位开发人员提到我们应该考虑微服务，因为客户提到了 CQRS。这两个连接了吗，我的意思是你需要微服务吗？我认为微服务在这里有点过头了，因为最终会有一个应用程序和一个数据库，而不是 6 个可以共享多个 API 的独立系统。我能看到微服务的唯一优势是部署，但除此之外，我认为单个 API 就可以了。

Answer 1

你正面临一个经典问题。我们是为了凝聚力而将某些东西放在一起，还是出于某种原因将其分开。

在您的情况下，您正面临一个物理边界：“读取端”和“写入端”是否共享足够多以至于值得将它们归巢在同一物理边界（单个部署单元）内，或者是否值得将它们归巢为两个单独的物理单元（两个部署单元）。

在 CQRS 场景中，出于以下几个原因，物理分离是有意义的

1. 模型通常不同。读取模型针对呈现给用户或需要信息的系统的内容进行了优化，而写入模型通常更丰富，因为它修改域、需要验证和应用其他业务规则。
2. 读取通常更频繁地出现在解决方案中，因此需要一组不同的比例因子。当这些因素可以独立于写入端时，就可以解决这些因素。

   此外，如果您的 CQRS 是“纯”或接近它，则意味着“修改”访问将访问与“读取”访问不同的数据存储。

   即使他们撞到了同一家商店，也可能仍然有理由将他们分开。在云世界里，做意味着单独的微服务。

   也就是说，我认为行之有效的一种方法是：围绕不同的需求创建逻辑解决方案。最初创建物理解决方案，将这些逻辑需求共同容纳在同一空间中（例如，一个微服务） .如果规模、性能、测试、耦合或其他力量表明物理中断，那就接受吧！寻求单独的微服务。

   最后，它来到事情是否有效，并且运作良好现在或永远在单个微服务（部署单元）中，还是以后在单独的物理实例（微服务）中工作得更好。

   总之，逻辑设置/实施绝对需要预先考虑。身体也应该被考虑在内，但最初并不那么重要。当将逻辑结构分解为物理结构时，您会发现这比最初从物理结构开始时更容易做到。