我们正在开发采用消息模式和微服务来定义和运行业务流程的解决方案。
它应该有这样的组件：
我们应该能够定义多个流程，其中每个步骤都是调用不同的服务。
一项服务的输出可以输入另一项服务。问题是它们可以有不同的模式，因此应该以某种方式对其进行转换/规范化。
但是应该由哪个部分负责进行这种转换呢？它应该是可配置的，因为我们想在不重新部署的情况下添加新流。
第一个想法是存储来自每个服务的响应，然后每个步骤将使用 XSLT 转换从以前的响应中生成输入 xml。但这可能是配置地狱，因为创建和测试这样的 XSLT 并不容易
您对如何正确解决这个问题有什么建议吗？
【问题讨论】：
标签： architecture soa transformation microservices
【讨论】：
如果您有由多个独立编写的组件处理的长消息流，您应该使用组件特定的数据格式。
由于Conway's law，您的组件应该属于对领域模型有不同看法的不同业务实体。例如，“订单”可能意味着完全不同的东西，需要为不同的部门提供不同的数据。
至于您的问题 - 每个组件都应发送特定于其业务实体的消息。接收方知道不同业务世界之间的优势，应该对传入的消息进行转换和丰富，以便进一步处理。
当然，需要额外的数据来进行丰富。它必须由拥有字典和配置的其他服务提供。
附： “添加新流程而不重新部署”是许多项目失败的主要原因。首先，没有理由担心在现代架构中重新部署 - 您的所有服务都必须集群化并优雅地处理故障。其次，您应该严格定义通过更改配置/规则/等可以做什么，不能做什么。更重要的是，世卫组织可以做到这一点。不要指望业务人员默认编写业务规则:-)
【讨论】：
假设您有多个系统提供服务，请使用规范数据模型以避免在中间件中嵌入转换。 Here is a link to Gregor Hohpe's enterprise integration patterns site about canonical models.
独立于任何特定的规范数据模型 应用。要求每个应用程序产生和消费消息 采用这种通用格式。
这个想法是有一个商定的标准，服务用于互操作。通常，每个提供服务的系统都有自己的内部数据模型，该模型不同于规范模型。发生这种情况是因为更改遗留系统过于繁重，或者规范模型不适合系统的内部数据表示。然后，每个系统分别负责将其内部模式转换为服务 I/O 的规范模型。
每个系统团队都可以使用其想要执行转换的任何工具：XSLT、Python 脚本、Java 或 Oracle 或 Microsoft 的某些所见即所得工具。结果是任何内部数据模型与规范模型不同的系统都必须执行一些映射。这是不可避免的。
【讨论】：