microservices - 如何在微服务中使用 Clean Architecture？

Question

我刚读完鲍勃叔叔的“清洁架构”，现在想知道如何在微服务的上下文中应用它!

一方面，我认为微服务属于“框架驱动程序”层，因为它是用例之上的实现(它们是为用例提供服务的方式。)这样，我们专注于应用程序的核心(实体和用例)，并在外层(包括微服务)的实现中保持灵活性。但是由于每个微服务都可以由不同的开发人员/开发团队维护，因此当用例发生变化时，他们会遇到困难(更难预测谁会受到影响)。

另一方面，我们可以将我们的应用拆分为多个微服务，相互解耦，并在每个微服务中应用 Clean Architecture。这种方法的优点是我们可以专注于每个微服务做一件事，并把它做好。但问题是我们开始使用技术分离(微服务)进行设计，这违反了专注于业务的主要清洁架构原则。此外，如果两个微服务使用相同的实体或用例，则很难不重复代码!

我认为第一个场景是最好的，但我想从其他开发人员那里得到关于这两个场景的长期好处和潜在问题的反馈。

Answer 1

正如@lww-pai-long 在他的回答中所说，基于域职责和 DDD 进行拆分在大多数情况下是最佳解决方案。
尽管如此，如果您使用使用微服务的系统工作，您很快就会意识到这里还涉及其他事情。

DDD 限界上下文作为微服务的基础

在大多数情况下，将您的应用程序拆分为基于限界上下文的微服务是安全的方法。根据经验，我什至会说在 Domain 的某些部分，您可以走得更远，每个有界上下文都有多个微服务。例如，如果您拥有代表一个有界上下文的域的很大一部分。其他示例是，如果您对特定域使用 CQRS。然后你可以最终拥有一个写入/域和 View /读取微服务。
您可以在此阅读 answer如何将域拆分为微服务。
正如您所说，“在每个微服务中应用清洁架构”是可取的。

Also, it will be hard to not duplicate code if two microservices uses the same entity or use-case!

在大多数情况下，这是您在使用微服务时必须处理的事情。跨多个微服务复制代码和/或数据是使用微服务的常见缺点。您必须考虑到这一点，因为另一方面，您要获得微服务及其数据库的隔离和独立性。这个问题可以通过使用共享库作为某种包来部分解决。请注意，这并非适用于所有情况的最佳方法。 Here您可以阅读有关跨微服务使用通用代码和库的信息。不幸的是，并非所有来自 Uncle Bob 的“Clean Architecture”的建议和原则都适用于使用微服务。

非领域或技术运营微服务

通常，如果您的解决方案使用微服务，您或多或少会拥有不特定于领域的微服务，而是直接进行某种技术任务或非业务操作的微服务。示例可能是这样的:

报表生成微服务

用于电子邮件生成和转发的微服务

用于授权/权限管理的微服务

用于 secret 管理的微服务

通知管理微服务

这些不是通过基于 DDD 原则拆分解决方案而获得的服务，但您仍然需要它们作为通用解决方案，因为它们可以被多个其他服务使用。

结论

在使用微服务时，您大部分时间都会混合使用特定于域和不可知域的微服务。我认为在使用微服务时，可以从稍微不同的角度看待 Clean Architecture。

On one hand, I think that microservices fall in the "Framework-Drivers" layer since it's an implementation on top of use-cases (they are ways to serve use-cases.)

它确实如此，但它也属于其他层，如实体和用例。我认为如果您从事特定于域的服务，这会朝着这个方向发展 Diagram成为每个微服务的架构，但不是所有微服务之上的概念。在我使用微服务的应用程序中，每个微服务(基于 DDD 限界上下文的那些)都拥有这些层的大部分，如果不是全部的话。域不可知服务是一个异常(exception)，因为它们不是基于域实体，而是基于某些任务或操作，如“创建电子邮件”、“从 html 模板创建 PDF 报告”或类似的“。