一個微服務對應一個有界的上下文嗎？

微服務定義
在我們檢視維基百科的定義之前，我們相信我們知道什麼是微服務。

“ 與SOA相比，微服務可以解決服務應該有多大的問題，以及它們應該如何相互通訊的問題。在微服務架構中，服務應該很小，協議應該是輕量級的。“

這個定義是我們行業的毛病：我們用別的東西來解釋一些我們也不瞭解的東西。我們是否對“ 小 ”和“ 輕量 ” 有什麼共同的理解？我不這麼認為。

更好的解釋是維基百科頁面細節中的第二個屬性：“ 服務是圍繞功能組織的，例如，使用者介面前端，推薦，後勤，計費等。 ”

公平地說，這個屬性與我們如何定義有界上下文有很多對稱性。

領域定義和問題空間
要了解有界上下文是什麼，我們需要定義域是什麼。它是問題空間中企業的理論表徵。它可以劃分為子域。
例如，在亞馬遜的知名企業中，核心域名是關於線上銷售內容，並且有不同的子域或多或少的通用，如運輸，計費，廣告等。
我們處於問題空間，因為我們還不知道如何實施亞馬遜的業務，它只是對他們所做工作的理論描述。

有界上下文定義和解決方案空間
有界上下文是解決方案空間中的投影，用於定義實現域的系統中的邊界。有限的上下文很重要，因為它們允許定義一種無處不在的語言，但是隻在其邊界內有效。結算有界上下文中的產品與運輸有界上下文中的含義不同。

如果做得不好很糟糕時，我們會獲得一個大的泥球，例如一個沒有邊界的龐大系統，其中計費部分的更新可能會導致運輸部件產生副作用。

我們處於解決方案領域，因為它是有關我們如何實現領域的實際描述。有界上下文不一定恰好匹配一個子域。但是，如果在不同的子域之間存在太多有界的上下文，這絕對會散發一種設計氣味。

一項微服務應涵蓋一個有界的上下文？

現在我們定義了微服務和有界上下文，我們可以嘗試確定一個微服務是否應該涵蓋一個有限的上下文？
當然，我們仍然無法決定，因為我們仍然缺乏（業務）背景。在某些業務環境中，微服務可能適合有界的上下文。在其他一些方面，一些微觀服務將在一個有限的上下文下。我們唯一能想到的是，重疊不同有界上下文的微服務是有些不對勁的。

像任何DDD討論一樣，上下文是王道。