領域驅動設計（2）怎麼使用溝通

廢話

        溝通的重要性：溝通很重要，不論在生活中，還是工作中溝通處理不好，我想為人處事這塊肯定有問題.LZ接觸社會比較早，做過焊工、銷售、跑過業務...，一路走來在溝通上同樣的也吃過很多的虧，受了不少的不會溝通的害處。我在做業務的時候常常用一句話告誡自己“一句話能死，一句話能活”，可能因為一句話業務活了，可能一句話面試活了，可能一句話感情有了....可能性很多，其實這可能的情況都是機遇只不過有大有小罷了.

領域驅動設計中的溝通：

有很多的項目是處於這一種情況,甲方（也就是領域驅動中的專家）不懂技術，不懂什麼是開發，沒有開發的思想，唯一知道的是我想要什麼的系統、功能或產品。因為領域驅動提倡的是開發人員和領域專家有交流和溝通的，那麼在平常開發的過程中常常會有這樣的事情發生，業務人員和甲方溝通過業務之後，把需求帶了回來，開發人員根據對甲方業務需求的分析進行設計開發，功能完成後，甲方驗收的時候發現不是自己想要的結果，這樣的後果在做項目的角度上無疑是非常嚴重的，不僅僅是延長了項目的完工時間，同樣也打壓了團隊的氣氛以及積極心態，為什麼會造成這樣的事情的發生，會不會是甲方描述的不清楚，也或者說是不是業務描述在傳遞的過程中有丟失...等等@可能有些人不認同了，為什麼沒有形成需求文檔讓用戶簽字確認等一些正規操作，這裡舉例說明的問題是相互溝通，相互瞭解。事實上一些好產品經理、團隊會和用戶進行深入的業務探討，往往針對一個需求，你來我往的戰鬥幾輪後才會產出需求、不管是反駁還是提出各種疑問或者是使用各種方法，如頭腦風暴、用戶故事、原型圖引導。。。等手段，這樣的深層次的溝通才會產出更加準確的需求，以此來減少需求的更改，也為項目的順利的驗收埋下了因，而不是簽字確認需求為以後甩鍋做準備。

在這種深層次溝通的情況下我們（乙方）講漸漸的融入進甲方的領域中，這個過程中我們積累了很多無形的財富，比如在公共語言上（在領域驅動設計中稱為：UBIQUITOUS  LANGUAGE 通用語言）將達成一致，當甲方使用他們自己的行話進行溝通的時候我們將不再迷茫，在種情況下進行溝通我們便可繪製出更加準確的模型，模型與模型之間的關係構建出了業務的規則，一些詞和短語也將反映出模型的含義。當所有的項目干係人都使用基於模型的語言來進行溝通交流，模型語言使用的越普遍，理解就越容易。切記的是在構建模型的過程中使用的通用語言應避免那些繞口、語義表述不正確的詞或語句，如果發現需儘快找到替代的詞或語句，通用語言越普通越貼近生活越容易理解。

舉例說明領域驅動設計語言如何使用

以下會出兩個例子做一個對比：

（1）沒有使用領域語言是這樣溝通的

新建四張表

一個簡單的用戶請求領域

在溝通過程中一般是這樣溝通的：

用戶：當我的銷售地區（Area）發生更改的時候，需要重新制定銷售方案嗎？

開發人員：是的銷售區域發生改變的時候我們需要刪除銷售方案表(SalesScheme)中的所有有關該地區的方案信息。然後將新的地區的信息通過服務去刪除然後重新制定新地區的銷售方案信息.

用戶：明白了，你們是刪除數據行項目，然後去插入行項目，但是如果我剛開始，我只知道哪些銷售地區需要需要放棄，但是我還不知道替換成哪些銷售地區怎麼辦呢，畢竟每個地區銷售的策略是不一樣的。

開發人員：這樣也沒有問題，服務對數據的操作很容易，咱們先清除放棄的銷售地區，等到找到替換的銷售地區我們再去添加也是一樣的。

用戶：可以，因為我們每次的制定一份銷售計劃需要花費很大的人力物力，一般情況下對於銷售方案部門不想去更改。

開發人員：我們通過銷售方案服務查詢出要放棄地區的銷售方案信息進行列表顯示，然後與新地區的銷售方案進行一個對比，看看是否有沒有制定新的銷售方案的必要。

用戶：我明白了。

現在很多開發團隊使用的對話方案，看起來完成用戶的需求也是沒有問題的。

用領域模型進行討論：

用戶：當我的Area（銷售地區）發生更改的時候，需要重新制定銷售方案嗎？

開發人員：是的Aera（銷售地區）發生改變的時候我們需要刪除SalesScheme(銷售方案表)中的所有有關該Aera（銷售地區）的方案信息。然後將新的Aera的Scheme（方案）信息通過SalesSchemeService(銷售方案服務)去刪除然後重新插入新的銷售方案信息.到SalesScheme(銷售方案表)中。

用戶：明白了，你們是刪除SalesScheme(銷售方案表)行項目，然後去插入行項目，但是如果我剛開始，我只知道哪些Aera（銷售地區）需要需要放棄，但是我還不知道替換成哪些Aera（銷售地區）怎麼辦呢，畢竟每個地區銷售的策略是不一樣的。

開發人員：這樣也沒有問題，SalesSchemeService(銷售方案服務)對數據的操作很容易，咱們先清除放棄的Aera（銷售地區），等到找到替換的Aera（銷售地區）我們再去添加也是一樣的。

用戶：可以，因為我們每次的制定一份Scheme（方案）需要花費很大的人力物力，一般情況下對於Scheme（方案）不想去更改。

開發人員：我們通過SalesSchemeService(銷售方案服務)查詢出要放棄Aera（銷售地區）的Scheme（方案）信息進行列表顯示，然後與新地區的Scheme（方案）進行一個對比，看看是否有沒有制定新的Scheme（方案）的必要。

用戶：我明白了。

這是模擬針對同一個業務需求用不同的方式進行的相互討論，有人會想了你這不是換了一種交流方式嗎？我們開發設計上也是這麼做的啊，事實上很多公司都在這麼做，但是因為一些特殊的原因導致我們開發人員是接觸不到甲方的，大多數的場景都是通過項目經理或者產品經理給我們描述，其實換一種角度，項目經理/產品經理把甲方當做領域專家，開發人員也可以把項目經理/產品經理當做領域專家，其實這樣做也避免了很多摩擦風險，把很多愉快和不愉快的事情控制在了項目內部，但是在項目內部使用領域的UBIQUITOUS  LANGUAGE（通用語言）去溝通避免了對同一個業務不同的人產生不同的理解，開發人員不在使用自己的語言去溝通去設計，使用同一種語言去溝通，是開發人員之間省去了不必要的翻譯工作，在和項目組其他干係人去溝通的時候很少會出現（聽不懂、你再說一遍、等一下我記一下、來麻煩重新描述一下、你看我這樣理解對不對呢、等等）這樣的情況，因為使用同一種語言描繪出的業務，大家都會明白的，這樣對執行效率、準確性以及代碼質量會有很大的提升。就是相互之間請別人幫忙查看一下（code review）代碼的時候也會方面很多。通用語言使用的越多記憶越牢固。

在我的真正項目經歷中令我印象最深的一次是，我們的主系統，是有很多個子系統組成的，我們項目組負只責其中一個系統模塊，同時參與該系統的還有多個團隊，所有子系統的功能性測試已經完成，要進入流程性測試的時候，再一次會議上發生了這樣的事情，甲方在很賣力講測試業務流程的時候我很驚奇的發現在場的大多數人員都處於一個懵逼狀態，當然也包括我（哈哈）舉個例子：在做一個反向訂單業務的時候我們在項目中稱為“反向訂單”，到甲方這裡稱為“散件入庫”這隻是其中的一個，總之當時給我的感覺就是我是不是進錯會議室了。

當然模型的制定不會是那麼順利的，這個過程相當於讓甲方學習了一門新的語言了，但是如果在項目的一開始我們就帶入模型的概念，從文檔，原型、示例圖、PPT、各種圖、會議上等都帶入模型的概念，慢慢的也都習慣了，時間長了大家就都會認為這是合理的了，時間能消磨很多棱角的。

在第二個示例（用領域模型進行討論：）中我們很明顯的可以發現在溝通的過程中使用了很多的模型中的關鍵詞或者短語進行著溝通，其實精簡模型的最有效的方式就是溝通，再通過溝通的過程中儘可能多的使用模型中的術語，這樣我們才有可能找出更多的模型變化，然後找出一個最精簡的變化去更新模型，其實這樣的好處不僅僅是對模型的精簡，也是對程式設計，對代碼的精簡，也就是說在我們日常的溝通過程中其實已經在對怎麼做出高質量的產品做著研究或者是改變的、這個過程也是在對代碼做著不斷的重構動作（語言的使用十分重要）

最近一兩個月將持續更新領域驅動設計。有偏差的望大家指出，相互學習。 

              有不足之處 希望大家指出相互學習，

                                   本文原創：轉載請註明出處 謝謝！