我是微服务的新手，并试图将大型整体应用程序分解为微服务。在确定微服务范围时，我无法决定是否应该在服务之间进行数据复制，或者通过将所有需要相同数据的服务合并到 1 个服务中来忽略 SRP。以下是场景。
我有一项服务接收客户订单，说用这些零件和功能建造一辆汽车。现在我有其他 2 个功能，它们使用部件和功能来导出一些运行时值；
如果订单包含部件 A 和功能 A，则执行 X 操作。由于每个功能都有各自的 UI 用于配置和运行时引擎来导出输出，并且大多数情况下更改仅出现在这些各自的功能块中，因此我考虑创建单独的微服务。
创建单独的微服务需要复制数据（部件和功能）。另一个选择是，每个服务都使用相同的数据，将它们全部合并为 1，但这样我会再次创建一个大型服务，如果该服务出现故障，将停止所有 3 个功能，并且违反 SRP。另一种选择可能是当其他 2 个服务需要数据时，进行调用并从订单服务获取数据，但这使其高度依赖并通过网络获取每个操作的数据。
任何人都可以建议在这种情况下最好做什么。
这是我的免费书:)
\n\n如果你想创建微服务，那么需要遵循微服务指南。
\n现在回到现实世界:)真的很难满足所有微服务要求，因为数据库有自己的许可成本等，所以你可以选择实用的微服务。您可以更快地开始使用它们，并挑选对您的团队有意义的部分。
\n设计领域驱动的面向设计的微服务：DDD 将问题视为领域。它将独立的问题区域描述为限界上下文，每个限界上下文都与一个微服务相关。
\n在哪里划定边界是设计和定义微服务时的关键任务。
\nDDD 模式可帮助您了解域中的复杂性、每个限界上下文的域模型，您可以识别和定义对域进行建模的实体、值对象和聚合。您构建并完善包含在定义上下文的边界内的域模型。这以微服务的形式是明确的。这些边界内的组件最终成为您的微服务。
\n现在，您可以在微服务之上创建层，并使用编排和编排构建复杂的逻辑。
\n例子 ：
\n网关 \xef\x83\xa0 客户订单 \xef\x83\xa0应用层微服务 --\xef\x83\xa0域模型层微服务 \xef\x83\xa0 基础设施层
\n