一个微服务对应一个有界的上下文吗?

18-11-29 banq
         

“ 一个微服务应该涵盖一个有界的上下文 ” Vaughn Vernon断言。它引发了与Greg YoungRomeu MouraMathias Verraes的有趣的讨论。Greg和Romeu不同意,我说这取决于上下文。

要知道一个概念是否可以覆盖另一个概念,我们必须知道微服务是什么以及有界的上下文是什么。我发现他们的定义很模糊,我认为这个讨论就是证明。我将试着澄清我在本文中的观点。

免责声明:以下定义是基于我目前对DDD战略模式的理解,我并未声称它们是唯一真正的定义。

微服务定义

在我们查看维基百科的定义之前,我们相信我们知道什么是微服务。

“ 与SOA相比,微服务可以解决服务应该有多大的问题,以及它们应该如何相互通信的问题。在微服务架构中,服务应该很小,协议应该是轻量级的。“

这个定义是我们行业的毛病:我们用别的东西来解释一些我们也不了解的东西。我们是否对“ 小 ”和“ 轻量 ” 有什么共同的理解?我不这么认为。

更好的解释是维基百科页面细节中的第二个属性:“ 服务是围绕功能组织的,例如,用户界面前端,推荐,后勤,计费等。 ”

公平地说,这个属性与我们如何定义有界上下文有很多对称性。

领域定义和问题空间

要了解有界上下文是什么,我们需要定义域是什么。它是问题空间中企业的理论表征。它可以划分为子域。

例如,在亚马逊的知名企业中,核心域名是关于在线销售内容,并且有不同的子域或多或少的通用,如运输,计费,广告等。

我们处于问题空间,因为我们还不知道如何实施亚马逊的业务,它只是对他们所做工作的理论描述。

有界上下文定义和解决方案空间

有界上下文是解决方案空间中的投影,用于定义实现域的系统中的边界。有限的上下文很重要,因为它们允许定义一种无处不在的语言,但是只在其边界内有效。结算有界上下文中的产品与运输有界上下文中的含义不同。

如果做得不好很糟糕时,我们会获得一个大的泥球,例如一个没有边界的庞大系统,其中计费部分的更新可能会导致运输部件产生副作用。

我们处于解决方案领域,因为它是有关我们如何实现领域的实际描述。有界上下文不一定恰好匹配一个子域。但是,如果在不同的子域之间存在太多有界的上下文,这绝对会散发一种设计气味。

一项微服务应涵盖一个有界的上下文?

现在我们定义了微服务和有界上下文,我们可以尝试确定一个微服务是否应该涵盖一个有限的上下文?

当然,我们仍然无法决定,因为我们仍然缺乏(业务)背景。在某些业务环境中,微服务可能适合有界的上下文。在其他一些方面,一些微观服务将在一个有限的上下文下。我们唯一能想到的是,重叠不同有界上下文的微服务是有些不对劲的。

像任何DDD讨论一样,上下文是王道。