微服务数据“所有权”是否意味着数据“理解”？答案

【问题标题】：Does microservice data "ownership" mean data "understanding"?微服务数据“所有权”是否意味着数据“理解”？
【发布时间】：2019-03-16 02:58:26
【问题描述】：

假设一个企业实体的“全貌”是这样的

{ 
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   foo: 5,
   bar: "something",
   baz: [1.0, -4.3]
}

但无论出于何种原因，我们都决定应该有一个 foo service、bar service 和 baz service 以类似的方式拥有各自的数据片段

{
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   foo: 5   
}

{ 
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   bar: "something"
}

{ 
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   baz: [1.0, -4.304]
}

但是，让我说一下我对系统的注意是

数据总是需要组合并应用一些业务逻辑来做任何有意义的事情。有一些单独的服务，它们的全部工作就是从上述服务中打包数据。
上述服务需要“理解”彼此的数据，以便对自己的数据进行有意义的工作。例如，bar 服务不能只知道“foos 是具有标识符和其他我不需要了解的属性的东西。”

你会说这是设计的味道吗？

【问题讨论】：

标签： design-patterns service architecture microservices

【解决方案1】：

首先，如果您选择微服务架构，您需要准备好接受lot of overhead 编排服务，划定正确的边界并建立每个服务之间的依赖关系较少或不存在。在characteristics of microservices. 上阅读并了解更多信息。

所以，对于您的问题，如果您有 3 个服务并且它们需要彼此来理解它返回的数据，可能您有设计气味。维护这样的架构将非常困难，因为对一个架构的更改可能会给另一项服务带来额外的问题。即使在同一个应用程序中，您也不希望仅仅为了这样做而拆分为 3 个服务，除非有任何显着的好处。

【讨论】：

【解决方案2】：

微服务完全可以捕获、存储和推理源自其他服务的数据位。

仅仅因为每个微服务都有自己的canonical model 并不意味着它不能导入其他地方定义的概念或用自己的术语重新定义它们。

Eric Evans 有一个很棒的presentation 关于限界上下文/微服务，它向您展示了集成选项的多样性。

【讨论】：

【解决方案3】：

这是非常少的上下文 :) 但正如所写的那样，服务似乎过度耦合，因为它们都需要彼此的所有数据。

请注意，服务不需要不知道其他服务的数据。事实上，服务之间完全独立的情况很少见——业务价值通常发生在交互上，例如对于目录，项目描述可能来自一项服务，基本价格可能来自另一项服务，这些只关心项目 ID，但特定客户的自定义价格将取决于来自基本价格和客户属性和服务的数据计算自定义价格需要了解它所使用的两种服务的数据。

服务应该是某些信息的所有者（负责创建、提供真相）。其他服务（和客户端）应该使用该信息 - 但如果它们都是相互依赖的，那么这可能过于耦合

【讨论】：