“ 一个微服务应该涵盖一个有界的上下文 ” Vaughn Vernon断言。它引发了与Greg Young，Romeu Moura和Mathias Verraes的有趣的讨论。Greg和Romeu不同意，我说这取决于上下文。
要知道一个概念是否可以覆盖另一个概念，我们必须知道微服务是什么以及有界的上下文是什么。我发现他们的定义很模糊，我认为这个讨论就是证明。我将试着澄清我在本文中的观点。
免责声明：以下定义是基于我目前对DDD战略模式的理解，我并未声称它们是唯一真正的定义。
微服务定义
在我们查看维基百科的定义之前，我们相信我们知道什么是微服务。
“ 与SOA相比，微服务可以解决服务应该有多大的问题，以及它们应该如何相互通信的问题。在微服务架构中，服务应该很小，协议应该是轻量级的。“
这个定义是我们行业的毛病：我们用别的东西来解释一些我们也不了解的东西。我们是否对“ 小 ”和“ 轻量 ” 有什么共同的理解？我不这么认为。
更好的解释是维基百科页面细节中的第二个属性：“ 服务是围绕功能组织的，例如，用户界面前端，推荐，后勤，计费等。 ”
公平地说，这个属性与我们如何定义有界上下文有很多对称性。
领域定义和问题空间
要了解有界上下文是什么，我们需要定义域是什么。它是问题空间中企业的理论表征。它可以划分为子域。
例如，在亚马逊的知名企业中，核心域名是关于在线销售内容，并且有不同的子域或多或少的通用，如运输，计费，广告等。
我们处于问题空间，因为我们还不知道如何实施亚马逊的业务，它只是对他们所做工作的理论描述。
有界上下文定义和解决方案空间
有界上下文是解决方案空间中的投影，用于定义实现域的系统中的边界。有限的上下文很重要，因为它们允许定义一种无处不在的语言，但是只在其边界内有效。结算有界上下文中的产品与运输有界上下文中的含义不同。
如果做得不好很糟糕时，我们会获得一个大的泥球，例如一个没有边界的庞大系统，其中计费部分的更新可能会导致运输部件产生副作用。
我们处于解决方案领域，因为它是有关我们如何实现领域的实际描述。有界上下文不一定恰好匹配一个子域。但是，如果在不同的子域之间存在太多有界的上下文，这绝对会散发一种设计气味。
一项微服务应涵盖一个有界的上下文？
现在我们定义了微服务和有界上下文，我们可以尝试确定一个微服务是否应该涵盖一个有限的上下文？
当然，我们仍然无法决定，因为我们仍然缺乏（业务）背景。在某些业务环境中，微服务可能适合有界的上下文。在其他一些方面，一些微观服务将在一个有限的上下文下。我们唯一能想到的是，重叠不同有界上下文的微服务是有些不对劲的。
像任何DDD讨论一样，上下文是王道。