我有以下情况：
您可以通过application-service创建应用程序。 在创建应用程序之前，需要检查特定信息。这些信息是分布式的，只能通过用户服务和产品服务进行访问。
第一个想法是通过服务总线通过所有服务发送一条消息，并通过所有必要的数据对其进行扩展，最后在应用程序服务中再次处理该数据：
->应用程序服务->用户服务->产品服务->应用程序服务
第二个想法是将所有相关数据冗余存储在所有服务中。意味着应用程序服务具有用户和产品数据的副本。
两个想法都不对。
有没有更好的方法？
答案 0 :(得分：2)
在您所描述的面向服务的体系结构中，在多个服务中复制数据是完全正常的，每个服务都扩展了特定于该服务的核心实体。
不过，我建议您重新考虑您的服务范围。服务是特定业务流程的技术权限。服务并非旨在与业务数据保持一致。
例如，您的Product Service和User Service听起来像业务数据，而Application-Service听起来太宽泛，而又不了解更多信息。
请考虑需要有关产品信息的Order-Service。它可以订阅来自ProductCreated的{{1}}事件，以使用产品信息填充自身，尽管可能只是一个ProductID。 Product-Service不需要知道产品的名称，描述，价格（可以在Order-Service服务中找到）等。
由于服务是业务流程的唯一权限，因此它也应该拥有用户界面。复合UI模式允许将包含来自多个服务的组件的单个页面放出来。 Billing将托管页面和将组件拉在一起的胶水。有关这方面的更多信息，我发现Micro Frontends很不错。