我们有不同的客户应用程序(每个应用程序都使用不同的UI构建，并针对不同的销售渠道)，用于捕获最终需要由我们的工厂处理的订单。
起初，我们决定提供一个单一的"订单"微服务，供所有这些客户端应用程序用于业务规则执行和数据存储。该微服务还将触发我们的后台流程，如客户档案更新、订单分析、文档存储到我们的电子金库、发票、通信等。
我们面临的挑战是，这些客户应用程序是由我们外部的团队开发的(我们只是一个后台团队)。每个负责开发客户端应用程序的团队都将能够为他们的用户提供不同的用户体验(有些团队将允许以不完整的状态保存订单，有些团队将使用特定的工作流捕获数据，有些团队使用文本字段而不是某些值的列表框，等等)
客户端应用程序行为的多样性是一个问题，因为我们的微服务逻辑将变得非常复杂，无法支持所有这些UI需求。此外，每次对其中一个客户端应用程序进行更改时，我们都必须修改我们的微服务，这是一种强耦合的情况。
我的问题是：你对处理这个问题的最佳建议是什么？我们是否应该让每个应用程序以其想要的方式捕获数据(如果需要，将其保存在自己的数据库中)，并让它们仅在订单完成并符合API合同时调用我们的微服务？
我们是否应该保持为每个人提供单一"订单"微服务的想法，并强制每个客户端应用程序以相同的方式捕获数据？
还有其他选择吗？
我们希望减少生态系统中数据和业务规则的重复，但同时我们也不希望我们的"订单"微服务变得一团糟。
非常感谢你的帮助。
此外，每次对其中一个客户端应用程序进行更改时，我们都必须修改我们的微服务，这是一种强耦合的情况。
这给我敲响了警钟。对UI的更改不需要对后端服务进行更改。(例外的情况是，如果系统中添加了一个新功能，而后端服务需要在支持该功能方面发挥作用，但我不会仅仅称之为对客户端的更改。)正如您所说，这是一种强耦合，这是微服务环境中需要避免的。
理想情况下，您的服务应该提供一个通用的、编程的API，它足够灵活，可以支持多个UI(或其他非UI应用程序)，而不需要了解UI的工作方式。
听起来你需要做出一些决定，决定你的服务将承担什么责任，不会承担什么责任：
- 您的通用订单服务是否更有意义促进未完成订单的存储/检索/完成，或者迫使其客户在其他地方进行管理
- 您的通用服务是否更有意义提供帮助跟踪工作流的设施，或者强制需要该功能的UI在其他地方找到它
- 对于想要显示列表框的客户，您的通用订单服务提供有助于填充这些框的API有意义吗
我们是否应该让每个应用程序按照它想要的方式捕获数据(如果需要，将其保存在自己的数据库中)，并让它们只在订单完成并符合我们的API合同时才调用我们的微服务？
这实际上取决于您是否认为这是服务运行的最明智方式。每个UI的需求有多相似或不相似。如果5个UI中有4个具有相同的需求，那么在您的服务中通用地支持它是有意义的。如果每个UI的行为与其他UI不同，那么将该功能放在通用订单服务中就相当于将前端代码存储在不属于它的地方。
这些决定似乎也有一些组织方面的考虑。如果使用您服务的团队仅为前端团队(即没有能力/技能来构建后端服务)，则仍有人需要构建他们所需的后端功能。
我们是否应该保持为每个人提供单一"订单"微服务的想法，并强制每个客户端应用程序以相同的方式捕获数据？
支持为每个人提供通用接口的单一订单服务。关于强制客户端应用程序以某种方式捕获数据，您的API只会规定它们需要做什么来创建订单。在调用您的服务之前，您不能(也不应该)对他们捕获数据的方式强加任何东西。他们可以随心所欲。真正的问题是您的服务是否支持各种捕获模式，还是将这种责任推回到前端。
处理此问题的最佳建议是什么？
与将使用该服务的团队合作。收集尽可能多的关于他们打算使用它的用例的信息。发现对大多数人来说什么是常见的，并选择你将支持的。创建一个半正式的规范(例如文档齐全的Open API)，与客户团队共享，征求反馈意见，并进行迭代。对于UI中在客户端中不常见的部分，强烈考虑告诉这些团队，他们需要自己支持设计中的这些元素，尤其是如果它们代表了您端的重要工作。