我们正在努力建立一个新的系统（.Net），将客户现有的6个系统合并为一个，目前的6个系统都有不同的数据库，在讨论Web API的设计时，客户问我们是否可以遵循CQRS模式，我计划使用一个Web API，将控制器分解为查询和命令控制器，这些控制器又与服务（c#类）一起工作，这些服务也被分解为查询和命令控制器。
在其中一次会议上，另一位开发人员提到，既然客户提到了CQRS，我们应该考虑微服务。这两种服务是否有关联，我的意思是，您是否需要微服务来实现这一点？我认为微服务在这里是多余的，因为最终将有一个应用程序和一个数据库，而不是可以共享多个API的6个独立系统。我认为微服务的唯一优势是部署。但除此之外，我认为一个API是可以的。
1条答案
按热度按时间b1uwtaje1#
你正面临着一个经典的问题：我们是为了凝聚力而把某样东西放在一起，还是出于某种原因而把它分开。
在你的例子中，你面临着一个物理边界：“读取侧”和“写入侧”共享足够的空间以使得值得将它们引导到相同的物理边界内（单个部署单元）还是值得将它们引导到两个单独的物理单元中（两个部署单元）。
在CQRS场景中，物理分离有几个原因
1.读模型针对呈现给用户或需要信息的系统的内容进行了优化，而写模型通常更丰富，因为它修改了域，需要验证和应用其他业务规则。
1.读取通常在解决方案中出现得更频繁，因此需要一组不同得缩放因子.当这些因子独立于写入端时，可以对其进行处理.
此外，如果您的CQRS是“纯”或接近它，这意味着“修改”访问将命中与“读取”访问不同的数据存储。
即使它们访问同一个商店，也可能有理由将它们分开。在云世界中，这 * 确实 * 意味着分开的微服务。
也就是说，我认为一个行之有效的方法是：围绕不同的需求创建您的逻辑解决方案。首先，创建您的物理解决方案，以便在同一空间（例如一个微服务）中共同容纳这些逻辑需求。如果规模、性能、测试、耦合或其他因素建议物理中断，那么就抓住它！选择单独的微服务。
最后，问题是 * 事情是否工作，并且在单个微服务（部署单元）中现在或永远工作得很好 *，还是以后在单独的物理示例化（微服务）中工作得更好。
总而言之，逻辑的设置/实现肯定需要一些预先的思考。物理的也应该考虑，但它在最初并不重要。当把逻辑结构分解成物理的家时，你会发现这比你从物理结构开始更容易做到。