开放主机服务、发布语言和规范数据模型
开放主机服务（OHS）的发布语言可以被视为一种面向集成的模型，有助于简化 OHS 消费者的公共接口。发布的语言经过集成优化，并以更方便的模型向消费者公开数据，专门针对集成需求而设计。
当我们提倡每个有界上下文都有自己的内部（规范数据）模型的想法时，OHS 实际上将有界上下文的内部模型与用于与其他有界上下文集成的模型解耦。因此，有界上下文内部模型可以在不影响 OHS 消费者的情况下不断发展。
假设我们想要设计 OHS 甚至多个 OHS 的集成模型。难道我们没有在 ESB/SOA 时代用于集成的旧式规范数据模型的概念吗？事实上，可以说，为公共 OHS 设计集成模型甚至有助于实现交换上下文的概念：一个单独的有界上下文，主要负责转换模型，以便其他组件更方便地使用。
所以问题是：我们是否不会回到 SOA ESB 时代的“老派”规范数据模型，将交换上下文的概念作为独立的有界上下文来负责转换模型以便其他组件更方便地使用？如果不是，有什么区别？
The published language of the open-host service (OHS) can be seen as an integration-oriented model to help simplifying the public interface of the OHS consumers. The published language is integration-optimized and exposes data in a more convenient model for consumers, specifically designed for integration needs.
When we are promoting the idea that each bounded context has its own internal (canonical data) model, the OHS in fact decouples the bounded context's internal model from the model used for integration with other bounded contexts. So the bounded context internal model can evolve without impacting the consumers of the OHS.
Say we want to design the integration model of the OHS or even multiple OHS's. Don't we have here the concept of the old school canonical data model we used for integration in the ESB / SOA era? In fact one can say that designing the integration models for the public OHS even contributes to the concept of the interchange context: a separate bounded context mainly in charge of transforming models for more convenient consumption by other components.
So question is: are we not going back to the 'old school' canonical data model from SOA ESB era with the concept of interchange context as a separate bounded context in charge of transforming models for more convenient consumption by other components? If not, what is the difference?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论