我正处于一个大项目的分析阶段，该项目将使用微服务架构创建。我非常有信心（至少在未来 3 年）整个代码库将用 TypeScript 编写，并且大多数模型将在这些服务之间使用。
我计划使用微服务来构建它，因为每个模块都将是一个单独的 API，它将拥有其 REST 端点来处理与其职责相关的任务。例如，身份服务将处理注册、身份验证、令牌更新等...
我计划将每个服务创建为独立的 NestJS 项目。及其存储库、包、依赖项等...
但我有一个疑问：
这些服务是否应该在内部声明每个模型？即使它可能是在另一个服务中声明的相同模型？这可能会导致项目之间出现大量代码重复，对吗？
如果他们不这样做，他们应该定义模型的只读子集，仅包含他们需要的属性，这将是当“源”模型更改时跨不同服务保持子集更改的最佳方式？假设服务 A 定义了模型 X，服务 B 使用 X 的一个子集（称为 X1），服务 B 使用 X 的另一个子集（称为 X2）。每当某个属性可能发生更改（被删除、更改类型、名称或其他）时，当这些项目可能有 10 个、20 个或更多时，哪种方法是在每个项目之间保持此更改同步的最佳方法？
我很困惑，因为据我所知，微服务应该是独立的，并且拥有它运行所需的一切，所以遵循这个逻辑让我认为服务应该重新声明原始模型的相同副本或子集，住在另一个服务中。
但从代码重复的角度来看，这似乎是一种自杀，因为第一年我将是唯一从事这些项目的人。
我知道微服务架构更适合开发团队，但是团队会来，所以在不久的将来可能会有 3/4 的人在做它，每个人都会有几个服务需要维护并发展。
提前感谢任何愿意帮助我解决这个疑问的人！
微服务的重点在于它们可以独立更改和扩展。 共享这些模型将迫使这些服务一起迭代，并将强制强耦合（不好）。
要处理微服务架构中的共享域，请将绑定保持在最低限度。 当服务 B 使用服务 A 的输出时，仅映射服务 B 所需的位。服务 B 应该有自己的独立模型，该模型只关心服务 A 中 B 关心的内容。 这样，当其他东西改变服务 A 的模型时，服务 B 就不会关心。
如果所有这些东西都存在于同一个数据库中，那么您就没有微服务架构，您拥有的是整体架构。 整体架构不一定是坏事，它们通过具有一致的内部域而具有真正的优势，只是一旦变得太大就会出现问题。 但如果您已经以这种方式构建数据库，那么构建与之匹配的软件可能是最简单的。