在設計領域，DDD帶來的變化是什麼？在微服務方面，DDD又帶來哪些新思潮？目前實踐DDD最大的困難是什麼？11月30日，在由ThoughtWorks舉辦的領域驅動設計峯會DDD-China 2019上，InfoQ記者帶着這些問題對ThoughtWorks創新設計總監肖然進行了採訪。
DDD——設計團隊的新視角
十年前，設計領域提出了一個跟DDD類似的方法，名叫Design Thinking。Design Thinking某種程度上跟DDD有異曲同工之妙。
一般而言，設計思維強調兩點：
-
第一，設計一定是靠跨角色的協作才能碰撞出來的，因爲世界上充滿了不確定性，這跟DDD要求業務人員和技術人員統一語言繼而協作的道理是一樣的。
-
第二，設計思維在對問題和解決方案的認知上面，跟DDD的想法也是一樣的。從設計的角度看，更重要的一點是怎麼認知問題。
DDD的思想要求看待問題更加註重上下文，產生的不同解決方案是源於對同一個問題的不同視角。設計團隊接受DDD的概念本身沒有什麼難度，因爲其工作性質就是如此。在數字化時代以前，技術和業務的職責劃分很清楚，業務寫需求，技術寫實現。但隨着業務需求的頻繁變動，行業裏提出了敏捷開發、產品迭代。
在數字化時代，很多數字產品、數字服務必須要持續追求更好的業務體驗，回到對用戶的關注上。這個時候設計團隊需要被植入到整個產品開發過程中去，所以出現了與之前技術和業務協作同樣的問題，因此，DDD的概念在設計領域也開始被人們所關注。
設計領域本身產生了很多基於協作的方法和實踐，設計上可以學習DDD的地方是統一語言。DDD最具參考價值的地方在於其嘗試建立一套元模型，這套元模型能夠爲業務、技術、甚至設計人員所理解。在這一點上，如果能夠在持續改進的過程中引入DDD的思想建立統一語言，對設計本身非常有幫助。
肖然提出“設計域”概念的背景，在於數字化時代的設計，需要反覆嘗試和試錯，在問題和解決方案之間來回摸索，如果沒有讓設計、業務和技術人員共同認知到這是一種常態，協作就會出問題。認識到在工作中存在這樣的“模糊地帶”，處理方式上就應該避免一個問題點一個解決方案，而是多點發散，多點嘗試，最後找到最佳方案去規模化實現。
設計域的未來
數字化時代以前，設計實施後修改成本很高，比如智能手機的設計建模，樣機做出來後再修改的成本超過數十萬元。但在數字化時代，設計的成本大大降低。舉個例子，網頁上的A/B Testing，某種意義上既是問題又是解決方案，原因在於設計者也不清楚哪種方案更好，所以選擇讓用戶去做投票，收集到真正的使用數據，進而再決定合理的解決方案。
設計域目前存在的挑戰在於整個團隊如何切換固有思維，對於問題和解決方案的定義並沒有必要那麼明確。舉例而言，肖然在演講中提到的人類移民火星這件事情，如果把其當做一個問題，解決方案可能是讓火箭更廉價，怎樣重複使用火箭。換一個角度，如果說人類移民火星只是解決方案，問題就變成了如何讓人類成爲多星球的生物。
業務思考的人、設計思考的人和技術思考的人，他們思考的方式不一樣，最後的碰撞就是大家對問題和解決方案本身的劃分就不一樣，到了一定的時候，特別是面臨高度不確定性，爲什麼一定要劃分呢？爲什麼不能大家都認可處於這樣一個模糊狀態，我們要做的事情就是多點嘗試，然後得到多樣反饋，最後能夠更快迭代升級解決方案。
DDD跟Design Thinking很像，但它更偏重於技術人員。從技術的視角，要跟業務建立統一語言，同樣也要跟設計建立，否則僅僅依靠可視化的高保真圖去構建數字化產品和服務是無法應對現實中的不確定性的。肖然表示自己始終在嘗試將Design Thinking和DDD進行融合，因爲讓設計人員真正理解DDD的抽象概念和方法論還比較難。但很多DDD實踐，不少設計人員發現與Design Thinking的實踐很像，從而能夠產生更多的共情。
肖然認爲，目前的業務和科技已經融合的差不多了，設計將會在未來融入到產品迭代的全週期中。現在很多的所謂“標準事件”，實際是設計做完，技術實現。設計域未來會形成跨角色協作的公式，如何建立一套統一語言是當務之急，但是不是一定要DDD的模型卻未必。
DDD與微服務
有人說，託微服務的福，DDD的思想重新走向了流行。
肖然認爲，這個問題可以反過來說，目前微服務的劃分方法裏全球共識的就是DDD，但DDD的核心思想並不僅僅侷限於微服務本身，因爲微服務是一種架構風格，而DDD是一種思想。微服務定義的九大核心特質，跟DDD的原則是完全一致的，這在某種程度上也是業界願意在微服務上下文中採用DDD方法和實踐的原因。
另一方面，這也造成了一定的問題。舉例而言，在拆微服務的方法上，比如說數據導向的應用，很難用現在流行的DDD方法來實踐。但如果不用DDD的方式拆，用什麼拆又成了新問題。現在業界還是很缺乏相關的實踐經驗。在微服務的設計，特別是在服務劃分上，即使在DDD思想的指導下，也還是有很多方法需要持續沉澱和提煉。
作爲最近兩年的技術熱點，Service Mesh正在嘗試解決微服務整個生命週期管理中運營和治理高成本的問題，它會進一步推動微服務架構的發展。至於它會不會影響到接下來的微服務劃分，肖然認爲有可能。比如在DDD的限界上下文劃分中，如果你據此劃分微服務，考慮到安全、信息傳輸等約束時，Service Mesh作爲一種微服務架構的落地實例化，很可能讓你在劃分的時候有更多的靈活度。但也因爲Service Mesh本身還不成熟，國內也就幾家貢獻者，工業應用案例不多，所以未來還不好說。
DDD：火爆與困局並存
DDD理論最早提出在2004年，此後的十餘年時間裏一直不溫不火，直到最近兩年纔得到了越來越多的關注度，原因何在？
肖然認爲，從全球看主要原因就是歐美企業的IT化進程已經走完，進入了數字化時代。在這個過程中發現軟件服務的領域差別特別大，由此帶來的不同領域的軟件開發難度也有很大不同。而DDD思想的核心在於建立統一語言所帶來的上下文一致，這對解決不同背景人員理解業務問題上下文不一致的挑戰非常有幫助。這是DDD在全球範圍火起來的原因。
在中國火起來的一個核心因素就是中臺概念。中國企業在過去的兩年間頻繁提及上雲，但在上雲過程中卻發現很困難，因爲軟件應用架構過於笨重。上雲終歸是繞不過去的趨勢，中國企業如何上雲？就是要調整原有架構，使其適應雲時代的要求。如何調整架構？DDD的思想比較合適，因此DDD在中國流行的原因不同於歐美，主要在於上雲要求的架構調整痛點。
DDD可以理解成一個架構的設計思想，通過DDD指導中國企業去做雲時代的架構建設。
目前DDD思想在國內雖然漸趨流行，但同樣面臨着諸多問題。現階段最大的障礙，跟當年敏捷開發面臨的障礙是一樣的，即如何調整組織架構。
過去業界提到敏捷開發，都說對個體的要求太高，但實際上並不是。表面上看敏捷對開發人員的技能要求高，實際上是因爲敏捷開發要求調整組織架構，很多人不願意動，因此業務和技術協作上的問題很難解決。
DDD面臨的困境同樣如此。在過去，技術這條線的劃分可能是開發一部、開發二部，業務這條線的劃分可能是業務一線、業務二線。但DDD的劃分理念是從業務角度劃分成領域，領域再劃成服務，落地的時候採用微服務架構，以前的劃分方式完全適配不了。所以直接造成DDD落地難的阻礙也是組織結構。具體表現就是協作不起來，各條線相互甩鍋，領導抱怨團隊人員能力不夠。
肖然認爲，如果企業確定要走DDD指引的架構方式，那麼其組織結構就一定要按照領域劃分。不見得未來所有企業最後的IT、數字化平臺就是領域化的，但如果確定了走領域驅動，那就一定要調整組織架構以適配DDD思想，如果不走，那就沒必要爲了DDD而DDD。
軟件開發沒有銀彈，中臺不是，DDD也不是。唯一有的，是不斷擁抱變化的業務與場景，讓軟件架構從變化中持續生長開來。