在QCon倫敦2016大會上，《領域驅動設計》一書的作者Eric Evans提出，使用領域驅動設計（DDD）概念減少微服務環境中通用語言的復雜性。
團隊使用不同的通用語言給管理微服務環境帶來了特殊的問題。團隊會開發自己的通用語言，并在自己的領域范圍內賦予它們意義。然而，這些通用語言的概念在團隊的語境之外并未保持一致。一個團隊對“客戶”的定義可能與另一個團隊的定義存在明顯的差別，導致了不必要的復雜性。此外，每一種語言都會在各自的團隊內發展演變，幾乎可以確定早晚會出現迥然不同的定義。
Evans談到，團隊會犯編碼錯誤及誤解需求，導致錯誤和糟糕的代碼。雖然這時有發生，但最壞的情況是這些錯誤滲透到了其他不相關的微服務中。Evans區分了他所謂的“小泥球”和“大泥球”，前者是指問題包含在一個微服務中，后者是指一個微服務中的問題擴散到整個環境。
Evans介紹了三種可以幫助管理微服務環境的DDD工具：上下文映射、“防腐層（anti-corruption layer，ACL）”和“交流語境（interchange context）”。上下文映射代表微服務間的通信路徑，暗含了微服務團隊之間的適當交互。一旦這種分析成熟，團隊就可以選擇依賴不同團隊的領域語言，在這種情況下，ACL可能就有意義了。ACL的職責是將外部概念翻譯成內部模型，從而實現領域間的松耦合。在兩個團隊需要更多合作的情況下，交流語境可能更有意義。交流語境比ACL更完善，它提供了一個層，供兩個團隊討論詞匯意思，并來回翻譯微服務語言。
將代碼從單體應用移植到一個微服務系統會把上下文復雜性從代碼轉移到微服務之間的空間。微服務之間的交互現在包含了邏輯，這些邏輯以前存在于易于閱讀和調試的代碼中。這種新的上下文必須妥善管理，否則整個系統就會發展成為Evans所說的“大泥球”。
Evans建議，將每個微服務設計成一個DDD有界上下文。這為系統內的微服務提供了一個邏輯邊界，無論是功能，還是通用語言。每個獨立的團隊負責一個邏輯上定義好的系統切片。最終，團隊開發出的代碼會更易于理解和維護。
京公網安備 11010502049343號