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