微服務架構如火如荼的發展了幾年後，在行業內已經被很多公司和團隊採用，微服務這塊兒看似美麗的蛋糕，，讓有的團隊敗走江湖，死的無比難看；也讓有的團隊順利完成轉型，積累了很多的行業最佳實踐。很多最佳實踐的最後都成爲了一個個的名詞，如玻璃碎一般，折射着神祕的光，實際上，這些最佳實踐，就是一塊塊拼圖，拼接起來，就是微服務的一個完整的版圖。
領域驅動設計
領域驅動設計以業務爲中心，劃分不同的領域，形成不同的限界上下文，不同的限界上下文實際上就是微服務該怎麼劃分的依據。
限界上下文的劃分不是單純的只有業務角度，技術實現限界上下文形成的例子比比皆是，例如高併發要求，數據的實時性的要求，第三方系統集成的需求，以及應對遺留系統等各個場景的要求。
限界上下文的合理劃分保證了各個服務模塊兒的高內聚，維持了各自上下文的領域模型一致性。
微服務設計的出發點之一是控制服務規模，各個不同的業務模塊分而治之，力求降低業務複雜度。但是微服務設計風格本身帶來的另外一些技術複雜度如果得不到合理的控制，很快就會吞噬掉分離業務複雜度的紅利。所以，分離業務複雜度和技術複雜度就成爲微服務的應有之義和目標。
由此，Devops應用而生。
Deveops
Deveops是開發和測試，運維的結合，力求做到開發，測試，運維的全鏈路自動化處理，以自動化來處理微服務劃分以後帶來的的運維和開發複雜度，提高開發和運維效率，由此，持續繼承和持續交付的理念誕生。
要做到持續交付，其中有一個環節必不可少，就是自動化測試，沒有測試，就無法保證的基本代碼的質量，代碼的質量都保證不了，何談交付？所以，TDD就成了在這個環節的行業最佳實踐。
TDD 和 敏捷
TDD 的全程是Test Driven Design ，並不是一個簡簡單單的先寫測試，後寫代碼，這個層次實在太淺了，關鍵在於Design，TDD的目的是指導我們通過測試的角度來設計可以測試的代碼和業務模型，讓測試一開始就成爲我們的安全防護網，防止我們的代碼和模型的錯誤發展和壞味道。從測試驅動的角度看，那句：“沒有測試的代碼，就是遺留系統”，毫不誇張，確實，你連測試都沒有，你怎麼拍着胸脯跟別人保證，我的代碼沒問題呢？
TDD 的另一個重要作用是：指導重構。在敏捷軟件開發，極限編程的風吹了十幾年後，絕大多數團隊和開發人員對敏捷的含義並沒有很深刻的理解，瀑布式開發依舊大行其道，一紙文檔依舊是很多團隊不同開發階段的標誌性輸出。敏捷的關鍵是什麼？答案是兩個詞語：快速和反饋，只有在快速反饋的前提下，敏捷所提倡的節奏才能形成。之所以在這裏提到敏捷，是因爲TDD對重構的指導作用，讓我想到另一個詞：有效。有效的反饋纔是敏捷的應有之義，這樣，敏捷的實際含義，應該是：快速有效反饋。TDD的節奏是：紅-綠-重構，這樣的快速節奏，和敏捷不謀而合。
領域驅動視角下的業務架構模型
回到領域驅動設計，微服務的出發點是達到技術複雜度和業務複雜度的分離，領域驅動的視角下，我們得到了完全不同於傳統MVC三層架構的代碼模型，整潔架構和六邊形結構瞬間讓我們醒悟到業務邏輯在代碼中的核心位置，而數據庫，第三方服務等徹底成爲了基礎設施（或者是南北向網關），通過抽象接口來隔離他們，層與層之間的關係，形成正交，彼此獨立演進，不會影響其他的層。這樣看來，微服務真的只是領域驅動設計下的一種部署形式和設計風格的最後體現，而正是這種體現，讓很多人在沒有弄明白微服務就下手後苦苦掙扎於技術複雜度泥潭而不自知的原因。
垂直細分的領域職能團隊
微服務考驗的不僅僅對於架構的設計能力和對於業務的理解能力，更是對傳統的團隊協作模式提出了挑戰。傳統的團隊協作模式下，開發，測試，運維，產品團隊都相互隔離，你走你的陽光道，我過我的獨木橋，唯一的關聯，似乎就是輸出的文檔，然而，文檔的準確度和實時性都和敏捷所倡導的快速有效反饋相悖。所以，邁入微服務時代後，端對端的開發垂直細分領域的跨職能特性團隊成爲了團隊合作方面的最佳實踐。康威定律告訴我們：任何組織在設計一套系統（廣義概念上的系統）時，所交付的設計方案在結構上都與該組織的溝通結構保持一致，小的團隊更能保證有效的溝通，保證更高的工作效率。
用戶故事
程序員與產品之間的梗在談論了很多年以後，至今也還是一個讓人津津樂道的話題。好多時候，這兩個羣體之間的思維是不在一個頻道上的，微服務的時代，產品的快速迭代，讓這種衝突更爲明顯。於是，有人探索出了在這個問題上的最佳實踐：用戶故事。
用戶故事的一般格式：
As a（作爲）<角色>
I would like（我希望）<活動>
so that（以便於）<業務價值>
用戶故事把用戶放在了需求的中心，以用戶的視角來描述需求，這樣，統一視角的敘述下，把最關鍵的事情描述清楚，定義出了對業目標的驗收標準。最關鍵的，每個用戶故事都是一個獨立的，完整的功能，不至於我們把所有的功能開發完之後，才能看到需求的全貌。
總結：
以領域驅動的視角去看待業務和設計項目模型，劃分限界上下文，得到一個個微服務的邊界；以Devops來自動化我們的開發流程，分離業務複雜度和技術複雜度，結合TDD的方式來引導我們寫可測試和可維護的代碼（也是可以測試的模型），落實敏捷開發的快速有效反饋；用端到端的的領域職能劃分團隊達到高效溝通；用用戶故事的方式描述需求，減少理解差異。這些行業最佳實踐的完整串聯，貫穿了一個項目從設計到開發，測試，上線，運維，迭代的整個生命週期。
微服務不是簡簡單單的接口RPC調用，它表達的是一種業務之間的高度自治和獨立進化；微服務只是一個服務的部署形式，它的內核是領域模型的設計和演化。只能看到微服務的技術層面，一直在這個層面徘徊，我們始終只是在微服務的大門口徘徊，疲於奔命的同時，感嘆需求的變化。
所以，想方設法落實行業最佳實踐，纔是微服這條路的康莊大道。