在2016年倫敦QCon大會上，《Domain Driven Design:Tackling Complexity at the Heart of Software》的作者Eric Evans提到在微服務環(huán)境下使用領域驅動設計的概念能夠減少普遍存在的術語復雜性。
微服務的環(huán)境下，團隊之間不相關的術語帶來了明顯的問題。一個團隊將開發(fā)他們自己的術語并且在他們的領域范圍內整理這些術語的含義。但是，在這個團隊之外，這些術語不能維持一致性。一個團隊對客戶的定義可能與其他團隊的定義不一樣，這帶來了不必要的復雜性。同時，每一個術語在所屬團隊內發(fā)展，幾乎可以確認完全不同的含義將會存在于同一時間或者其它時間。
Evans談到了團隊編碼失誤和錯誤理解需求最終導致錯誤和糟糕的代碼。雖然它只是偶然發(fā)生，但是當這個失誤滲透到其它不相關的微服務時，最壞的場景將會發(fā)生。Evans闡述了他所說的“小泥球”和“大泥球”之間的區(qū)別，前者的意思是所有難題在一個微服務內，后者意思是一個微服務中的問題將會擴展到整個環(huán)境。
Evans展示了3個工具用于幫助微服務環(huán)境下的管理：上下文地圖，ACL(反腐層)和交互上下文。上下文地圖描述微服務之間的溝通路徑并且建議微服務團隊之間進行適當的交流。一旦這個分析是成熟的，一個團隊可以選擇依賴另一個團隊的域術語，在這種情況下ACL層可能更清楚。ACL層的職責是把外部的概念翻譯成一個內部模型從而提供了域之間的松耦合。在兩個團隊需要多個合作伙伴關系的情況下，交互場景可能更清楚。交互上下文比ACL更強大，它提供了一個兩個團隊可以來回的討論他們的詞語含義以及轉換成微服務的術語的地方。
遷移代碼從一整塊巨石到一個微服務的系統(tǒng)是把一個上下文復雜性從一處代碼放到各服務之間?，F在微服務之間的交互包含了以前容易閱讀和調試的代碼中的邏輯。這個新的上下文必須是可管理的，或者整個系統(tǒng)轉移到了Evans所說的“大泥球“中。
Evans建議根據領域驅動設計邊界上下文設計每一個微服務。這將會在系統(tǒng)內部提供為微服務提供一個邏輯邊界依據功能和術語。每一個獨立的團隊承擔一份系統(tǒng)邏輯上定義好的部分。因此，團隊產出的代碼是更容易理解和維護的。
