在微服务架构中，主要规则是在各个设计级别（包括数据库和领域模型）拥有自治服务。然而，在类（模型）是基于 OOP 原则（例如继承）设计的应用程序中，并且某些类从其他类继承，将这些类分离到相关的微服务中会带来挑战。这样做会破坏他们之间的关系。符合微服务的独立设计，不允许共享任何域或类。此外，每个微服务都可以用不同的编程语言编写，这使得它更加复杂（共享域）。
我认为每个微服务中的类可以重复，因为我已经看到这种情况在某些项目中发生了很多，但这违背了 OOP 强调代码可重用性的目的。它还违反了 DRY（不要重复自己）原则。
你的想法是什么？你的解决方案是什么？
本着禅宗与摩托车维修艺术和哥德尔、埃舍尔、巴赫的精神：Mu。
每个微服务都可以用不同的编程语言编写
事实上，您可以用 Haskell 或 C 编写微服务，这两者都不是面向对象的（根本）。还有许多其他编程语言并不是特别面向对象，例如 F#、Python、OCaml、Clojure 等。虽然这些语言确实支持面向对象，但用这些语言编写的代码往往根据面向对象设计 (OOD) 以外的其他原则进行组织。
因此，询问如何在用 Java 和 Ruby 编写的微服务中应用良好的函数式编程 (FP) 原则与询问微服务中的 OOD 一样有意义。
对重复与重用的担忧是可以理解的，但我认为，如果您担心重要的域逻辑在多个服务之间重复，那么这些服务可能会沿着错误的路线分解。 领域驱动设计包含关于如何识别和分解有界上下文的很好的讨论。
如果您发现您的代码在一个微服务中更改代码，则还需要更改另一个微服务中的代码，则需要对这种耦合采取一些措施。 Adam Ralph 就此做了精彩的演讲：寻找您的服务边界 - 实用指南。
简而言之，OOD 和 FP 都不是跨微服务的正确组织原则。相反，在我看来，古老的 SOA 口号“服务是自治的”是最有用的指导原则。