2011年3月份還在華為夜以繼日的時候，買過一本《領域驅動設計：軟件核心復雜性應對之道》，雖然努力的看過一次，沒看懂，覺得都距離我很遙遠。2014年4月，在ThoughtWorks還不到一年，買了一本騰老板的《實現領域驅動設計》，看了一遍，似乎理解了一些，但還是有些摸不著頭腦。

　　做IT的一方面白天要鼓足干勁干好那8小時，回家每天抽時間陪小孩玩耍一兩個小時，另一方面又要在9點半之后盡快的吸取最新的營養，實乃不容易。回想起老婆回娘家的那段時間以及自己出差的一個月，真是非常難得，可以抓緊時間讀書、試驗新的技術。ThougtWorks的讀書文化我很欣賞，別個同事每年讀個50本書，我卻用Training Budget買了很多書回來，就放在那里了。這并不是說我費錢，主要是中國的出版業很奇葩，你不買可能過段時間就成絕版了，想買也買不到了。我每過一段時間就要清理了一下，感嘆一下書非借不能讀也，真想靜下心來重新讀書。

　　讀書，別開電腦，離開你的手機，摒棄一切的，拿上一支記號筆，開始吧。

　　重新讀《領域驅動設計：軟件核心復雜性應對之道》正是由于做到了項目的后期，覺得整個項目已經開始凌亂。大家對業務知識不了解，也沒問，只求趕緊將東西搞出來；對技術只見樹木不見森林，雖然有很精巧的重構，但無法反映出真實的業務場景；有多個的Micro Service但有些職責顯得混亂不堪。團隊在一個混沌的情況下越來越暈，我真是想找個時間重新審視一下這個系統，如何在新的一年有更好的發展？

　　第一章 消化知識

　　對于一個良好的系統而言，還是需要一個靠譜的模型。然而團隊并沒有給出這個模型，最早的時候都是按照View Model來建模，映射Field，然后對其進行處理。再引入了Micro Service后，情況有所轉變，因為Share的原因必須要讓開發者思考Domain Model，然后對頁面進行去耦合。這是一個好事情，但尚處于一個模糊的階段。

領域模型也迫使開發人員學習重要的業務原理，而不是機械的進行功能的開發。

　　這正是我們目前開發人員很缺的一塊兒。作為一個常見敏捷開發團隊，一般配置BA(業務分析人員)、DEV(開發人員)、QA(測試人員)。BA和業務人員談論需求，并且分解為Story卡，DEV可能會參與其中的技術討論，但對業務知識也只是一知半解，甚至都沒有對業務知識的追求。短時間內，這個也沒有太大的問題，BA充當了業務人員和開發人員之間的一個翻譯，但往往業務人員和開發人員之間存在了語言的障礙。

　　在之前的項目中，我也僅僅只作為DEV來實現一些需求。對于背后的業務邏輯，BA告訴我即可，別多想了。長此以往，DEV最后就真正的變成了Coding Monkey，而現實的情況是Coding Monkey越來越便宜。所以開發人員必須要逐漸的懂業務，從業務上思考問題，才能跳出Coding的圈子。

　　好在我們項目，由于BA的能力欠佳，我們不得不跳出常見的開發團隊，讓多個經驗豐富的開發人員嘗試更多的時間跳過BA直接和業務人員打交道。一來是意思傳達的更準確，二來是增進了開發人員和業務人員的交流。雖然這樣通常會讓開發人員多出20%-30%的時間用于更多的溝通，對于開發的效率有所影響，但總體而言物有所值。甚至Iteration Manager Fabio(我只能說和這樣的牛人一起工作實乃幸運)也鼓勵開發人員這么做。我想如果今年團隊能夠突破英語的障礙，直接和業務人員溝通，BA這個職位都可以淡淡的弱化了，人人當BA。當然還得感謝ThoughtWorks能夠有比較小的敏捷的團隊。否則類似于華為、中興這樣的大企業，開發人員幾乎沒有和業務人員溝通的機會，造成做了半天都不知道具體的業務場景是啥，寫出來的代碼難免會錯誤百出。

　　第二章 語言的交流和使用

　　混亂的語言

Ubiquitous Language，通用語言。

　　這種語言可以用于團隊的溝通，也可以用于描述軟件本身。于領域專家談話的時候也需要使用這種語言，能夠消除彼此之間的隔閡，讓開發人員更容易的理解業務。而開發人員也應該使用這種語言來闡述需求，消除模糊的語言。

　　然而我們沒有，甚至各種名詞彼此混淆沖突。舉一個現實的例子是ANZSIC和Occupation。ANZSIC是指The Australian and New Zealand Standard Industrial Classification，而Occupation是指在某業務部分對ANZSIC的細分用于更精確的定價及投保。

　　我剛到項目組的時候，就發現代碼中混淆著ANZSIC和Occupation這樣的類、字段和變量，問了兩三個人也沒解釋清楚，大家的理解這兩個東西好像是一回事。后續和業務人員溝通的時候，我們也會將ANZSIC說成Occupation，造成很多的混亂。甚至在做設計的時候，也會混用這兩個詞。我快要暈了。

　　我決定停止這樣的混亂，找業務人員問清楚。原來ANZSIC和Occupation比較類似，ANZSIC是4位編碼(例如3232)。而Occupation是對應的ANZSIC的擴展，例如3232對應的ANZSIC還不足以區分投保，所以Occupation再3232的基礎上再加2到4位，變成323201或者32320101。這樣就解決了ANZSIC細分粒度的問題。

　　搞清楚這個事情以后，寫到了一個Terms的文檔中，并且在整個團隊及相關的團隊中都共享這個知識，每次有人錯誤提及的時候我都會糾正一遍。這樣好歹基本上大家都搞清楚了。但這個混亂的成本也很大。代碼中的混亂，已很難改變。很多JSON對象中也是亂套的用，多個Micro Service的API也不好改，甚至有些本該是ANZSIC的寫成了Occupation，對類的重命名會造成類定義的混亂。這是個鮮活的例子，開發人員應該搞清楚每個名詞的真正含義并不斷修正之。

　　文檔在哪里

　　新加入團隊的成員很是不理解為什么代碼里面幾乎沒有什么注釋。作為一個自解釋的代碼，保持代碼短小，命名清晰，可以保證大部分時候不需要什么注釋。但千萬別走極端，代碼無法解釋的內容，例如一些比較難理解的設計用途，或者一些不通常的實現方法，都需要有一些注釋作解釋。

　　那么設計文檔呢？可能有時候開發人員過于自信自己的水平，認為可執行的測試就表明了一切，就不需要文檔。但他們可能沒有遵循TDD，造成測試遺漏；或者沒有能力管理好成千上萬的測試；或者測試命名、意圖描述的不準確。這些因素都可能造成一些歧義。讓一個新來的人員直接看這些測試，直接就會暈死在各種細節中。

僅僅使用代碼這一種文檔形式與過度地使用UML圖具有同樣的基本問題。文檔不應該重復表示代碼已經明確表達出的內容。

　　我們項目每個開發人員會負責一個特性，在每個迭代的分析階段會有一些文檔性的東西支撐。但我基本不會將代碼中實現的東西在文檔中又說一遍，例如類圖這種東西，一旦我重命名就完全不一致了。甚至API的設計，我只會說基本原則，并參考API測試，那里有你所需要的。最后，我會講解整個特性的基本實現原理及一些約束，這種代碼之外的補充文檔才是充分有用的。