如果您這些年來一直在企業軟體體系結構的任何地方工作，您很有可能會遇到諸如“什麼是微服務的正確粒度？”之類的問題。或“微服務和有界上下文是否相同？”

在接下來的幾段中，我將盡力澄清。

定義

我想澄清的第一個問題是，兩個概念都有一個模糊的定義。定義這些概念本身已經很困難，因此將兩者結合起來很容易使對話變得含糊不清。

有界上下文是圍繞語言構建的。

領域驅動設計的發明者埃裡克·埃文斯（Eric Evans）可能需要花費數天的時間尋找完美的詞語來傳達特定的含義，因此當他選擇一個詞時……這個詞只是可能代表他表達含義。因此，讓我們看看Context的原始定義，然後再看看有界上下文Bounded Context（原始資源在這裡）：

上下文：用來確定其含義的單詞或陳述的一種設定

這基本上是一個語言術語。關於世界各地的“ 咖啡 ”一詞的不同含義，有無數的故事和笑話，但這就是任何語言的本質。術語如果在其原始範圍之外被使用，最初聽起來像很奇怪的隱喻，逐漸這也成為對話語言的一部分，依此類推。

語言不是固定的，而是不斷髮展的。

語言不是固定的，上下文對於實現精度是必不可少的。

但是語言只能在一定程度上幫助我們：編寫軟體時，我們需要精度。當開發涉及多個上下文的軟體時，使某些對話聽起來像是在開玩笑的同樣模稜兩可的情況，將成為錯誤的危險來源。

那麼什麼是邊界上下文？

在軟體世界中，我們需要承擔為這種語言一致性設定邊界的責任。這就是“ 有界上下文”概念出現的地方。

有界上下文：特定模型的有限適用性。有界上下文使團隊成員可以有一個清晰的、共享地理解，這就是那些獨立開發的內容必須保持一致性。

這裡的定義更接近軟體開發領域。有一些隱含的假設，讓我們嘗試使其明確。

• 我們正在談論多種專業模型：不平常的軟體將需要不同的模型和不同的樣式進行協作。每個問題都會有一個最適合 該特定問題的模型。
• 團隊和有界上下文之間存在緊密的聯絡：具有明確目標的團隊很有可能圍繞其特定的問題空間發展出精確的行話。
• 一刀切的所有標準體系結構沒有用。就像在說“我們必須贏得一級方程式賽車冠軍”，同時說“所有員工，包括司機，應獲得相同的報酬”。(banq注：這些都是大話套話、正確廢話，無法付諸實現)

實際上，有界上下文使用這種語言作為煤礦中的金絲雀（banq注：用金絲雀測試煤礦中是否有毒氣，它們比較敏感，這也是測試領域的一個專業詞語：金絲雀測試）：語言對於來自不同來源（團隊成員，利益相關者，團隊分佈，基礎技術，時間等）的變化非常敏感。語言中會出現不一致之處，因此我們會留意。

保留邊界成為一項有趣的設計活動，因為它意味著通過實現介面卡或反腐敗層來推動邊界處的轉換，以使內部模型儘可能簡單，或者更好地專注於該特定模型的唯一相關問題。

（banq注：邊界敏感性和文化思維方式有關，如果文化中注重個人隱私邊界，會培養成對事物和人的邊界劃分敏感性，如果沒有這種文化，注重鄰里和諧打成一片，對培養邊界敏感性可能不利）

那麼什麼是微服務？

當要確切地瞭解微服務是什麼時，由於沒有單一的中央定義要引用，因此情況甚至更加嚴峻。但是，Martin Fowler’s Bliki 仍然可以作為權威資訊來源。

該術語嚴格來說是架構性的，但有趣的是，其含義正在整個社會技術體系中產生。

• 通過服務進行元件化 →這是最明顯的部分。它也是與SOA最相似的一種。作為獨立部署是一個重要特徵。
• 圍繞業務能力進行組織 →跨職能團隊為特定的業務目的服務。
• 產品而非專案 →團隊負責整個生命週期，包括生產和維護。
• 智慧端點和啞管道 →將邏輯置於通訊通道中最終會使供應商受益（具有可怕的鎖定方案），其想法不是要重蹈SOA中ESB供應商所發生的錯誤。
• 分散的治理 →本地選擇更瞭解本地問題：因此本地實施應該有更多的自由。（聽起來很像我們剛才所說的）
• 分散資料管理 →微服務應擁有自己的永續性。毫不奇怪，Fowler的文章直接提到了有界上下文的概念。
• 基礎架構自動化 →持續交付是必須的。為了提高質量，加快反饋迴圈等。
• 故障設計 →應用程式需要容忍服務故障，因此微服務方法的一部分涉及確保故障不會影響使用者體驗。到目前為止，Netflix是最著名的案例。並引發了有趣的想法，例如四面軍和混沌猴子。
• 進化設計 →並行獨立的進化也帶來了較小的，可能是不協調的發行版的想法。元件是可獨立更換的，並且使用壽命可能不同。

在這裡，我試圖將兩個概念的關鍵特徵重疊起來。

特徵有界上下文微服務相容性

這兩個概念一樣好像感覺不同但高度相容。

尋找完美的尺寸

它們不是同一件事：

• 顯然，您可以在不同的體系結構中使用有界上下文：它們比微服務早了大約十年。
• 只要滿足安全建議，您就可以在同一個部署單元內擁有多個有界上下文（例如具有乾淨內部分隔的整體）。
• 有界上下文圍繞內建目的的模式，微服務圍繞部署邊界。在某些情況下，驅動力可能相似，但並不相同。

在年輕的初創公司中，開發速度非常重要，因為我們要從頭開始構建許多元件，但是物理隔離不同的元件會減慢一切，並且在快速增長的環境中，邊界可能會模糊一段時間。常見的策略可能是在整體內部進行邏輯隔離，並僅在達到給定數字時才開始發展體系結構。

在中型公司中，不同的團隊已經可以與定義明確的部門合作。目的驅動的邊界可能與部署單元以及業務功能重疊。

在某些情況下，可以通過具有多個獨立模組的鬆散耦合元件來實現價值交付。在這種由Netflix聞名的場景中，元件比有界上下文小得多，並且通過諸如Chaos Engineering（Chaos Monkey和Simian Army是著名的例子）之類的激進方法來保持整體行為的完整性，以增強整個系統。

可能的經驗法則

我喜歡漸進式架構的想法，而不是預先進行大型設計。(banq注：敏捷？)

有界上下文應圍繞目標和語言邊界出現。戰略願景的事件風暴是突出並收集這些邊界的一種非常有效的方法。

微服務通常會在團隊規模和變更頻率附近找到獨立部署單元的最佳規模。最終部署在一起的拆分元件往往會因協調成本而適得其反，因此自主團隊傾向於找到自己的完美平衡。

錯誤的代價

錯誤大小的動態是不同的：太細粒度的有界上下文很容易混合，而分離這些已經混合的BC有界上下文則要貴得多。

微服務暴露出相反的風險結構：過於細粒度的服務會增加保持整體結構受控的成本，而將服務拆分成更明確的結構（可能保留前端API）則可以在分析實際服務後按需完成壓力。

這種相反作用力的結合通常要求：邏輯上保持邊界整潔，在有價值的時候進行物理隔離。

反模式

資料驅動的拆分（無需進行對業務行為的檢查和重新設計即可將資料庫表的應用直接轉換為微服務）也產生了驚人的反作用：新系統與其整體祖先耦合在一起，但速度可能較慢，並且重構成本飛漲。

超越技術

大多數從業者都擔心完美的尺寸和技術堆疊。但是真正有趣的屬性是在社會技術堆疊的社會部分。

有界上下文為這種實驗提供了隔離的空間。隔離是提供安全的基礎。如果您的模型與太多的參與者共享，人們將無法進行實驗，因為會破壞他人的程式碼。

良好的有界上下文提供了安全的空間和良好的責任迴圈。

我們是對此類程式碼負責的唯一人員。如果這裡有錯誤，我們不能怪任何人。但是我們可以確保程式碼中完全沒有錯誤。

這種不依賴其他團隊或其他技術的小技巧，與考慮周全的微服務似乎朝著同一方向發展，在反饋迴圈中增加了一些加速，因此領域學習和業務學習也可以通過生產影響快速得到驗證。

對我而言，真正使我震驚的是，有界上下文和微服務與丹尼爾·平克（Daniel Pink）《驅動器》的動機原則是融合一致的：自治，精通和目標。

• 在計劃，技術和思維模型方面，儘可能與其他團隊保持獨立。獨立性越高，指責遊戲和指責的可能性就越小。
• 致力於提供高質量的軟體並承受不良質量的後果，對於在真正重要的地方提高軟體質量是一個很好的環境。
• 與給定業務能力的直接連結將簡化與業務代表的互動，帶來更短的反饋迴圈，更多的學習機會，並最終開啟更具實驗性和可能的​​創造性對話的可能性。

換句話說：我們一直在技術和工程方面，因為這是我們擅長的，我們可能會忘記我們只是在為軟體專業人員建立一個更健康的工作場所。