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