微服务和规范模型

当我在该网站上阅读有关微服务的信息时，遇到了以下声明。规范架构是什么意思？与域模型不一样吗？

微服务架构模式还拒绝了SOA的其他部分，例如规范架构的概念。

事先依靠@ArseniMourzenko的评论道歉，但是当我开始阅读Wikipedia时，我立即了解了Canonical Schema的含义。

在此，OP的评论重点在于真正的疑问

我相信即使在微服务架构中，请求和响应也必须符合某些数据模型。

是一些数据模型，但是似乎本文是指两个或多个服务之间的“共享”或“公共”数据模型。

该规范模式是指在运行时数据转换服务保存的模式。这也使您免于复制代码。但是，然后您也将服务耦合到外部数据模型。（请参见上面链接的维基百科页面上的图）

这是服务之间的一种常见“语言”。

因此，看起来这篇文章正在强调MS与它所处的“生态系统”的完全独立性。

以对ESB的提及为例。

他们还非常避免使用ESB，而是在微服务本身中实现类似于ESB的功能。

ESB通常要求企业数据模型（消息），这对于连接到总线的每个人都是通用的。

因此，回到文章，作者似乎指出了MS拒绝附加到任何外部系统（及其约束）的事实。

微服务是关于紧密的凝聚力和松散的耦合。在微服务中，您具有紧密的凝聚力，但是在微服务之间，您的耦合松散，因此您要避免任何共享的架构或数据协定。如果发现微服务以要求它们共享公共模式的方式彼此进行同步调用，则可能表明您未正确定义服务边界。

用域驱动设计的话来说，微服务应该与绑定上下文紧密结合。