Question

让我们说一个企业实体的“整体情况”就像

{ 
   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]
}

但是，比方说，我对系统注意到的是

始终需要合并数据，并应用一些业务逻辑来执行有意义的事情。有一些单独的服务，其全部工作就是打包来自上述服务的数据。
上述服务需要“理解”彼此的数据，以便对自己的数据进行有意义的工作。例如，酒吧服务不能仅仅知道“ foos是具有标识符和其他我不需要理解的属性的东西。”

您会说这是设计气味吗？

Answer 1

首先，如果您选择微服务架构，则需要准备lot of overhead来编排服务，划定正确的边界并确定每个服务之间的依赖性很小或没有依赖性。阅读并了解更多关于characteristics of microservices.的信息。

因此，如果您有3个服务，并且它们彼此需要对方来理解所返回的数据，那么可能是您有一种设计味道。维护这样一种架构将非常困难，因为更改一个架构可能会给另一项服务带来额外的问题。甚至在同一个应用程序中，除非有任何明显的好处，否则您也不会只是为了这样做而将服务拆分为3个。

Answer 2

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

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

Eric Evans具有关于边界上下文/微服务的出色presentation，可向您显示集成选项的范围。

Answer 3

这是非常少的上下文:)，但是按照书面看来，这些服务似乎耦合过度，因为它们彼此都需要所有数据。

请注意，一个服务不需要知道其他服务的数据。实际上，很少有服务彼此完全独立的-商业价值通常发生在交互上，例如对于目录，项目描述可能来自一项服务，基本价格可能来自另一项服务，而这些仅关心项目ID，但是特定客户的自定义价格将取决于基本价格，客户属性和服务中的数据计算自定义价格需要了解其使用的两种服务的数据。

服务应该是某些信息的所有者（负责创建，是真理的来源）。其他服务（和客户端）应该使用该信息-但是，如果所有信息都是相互依赖的，那又可能太耦合了

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

3 个答案: