大家好，我是霸戈，這周學習了一些關於領域驅動設計的知識 ，對比較深刻的地方做了不少筆記，分享給大家。
在日常需求討論的時候，經常會碰到一個需求會議開了一個多小時還沒有達成共識。作爲業務方（領域專家）明明表達的很清楚，但是開發人員卻始終無法理解透徹，很明顯的原因就是由於雙方的知識體系不一致 ，沒有形成一種雙方互相都能理解的語言。
語言的鴻溝
雖然領域專家對軟件開的技術所知有限，但他們熟悉使用自己的領域術語——可能還具有各種不同的風格。另一方面，開發人員可能會用一些描述性的，功能性的術語來理解和討論系統，而這些術語並不具備領域專家的語言所要傳達的意思。
開發人員可能會創建一些用於支持設計的抽象，但領域專家無法理解這些抽象。負責處理不同部分的開發人員可能會開發出各自不同的設計概念以及描述領域的方式。
由於語言上存在鴻溝，領域專家們只能模糊地描述他們想要的東西。開發人員雖然努力的理解一個自己不熟悉的領域，但也只能形成模糊的認識。
雖然少數團隊成員會高法掌握這兩種語言，但他們會變成信息流的瓶頸，並且他們的翻譯也不準確。
相互翻譯使模型變得混淆
在一個沒有公共語言的項目上，開發人員不得不爲領域專家做翻譯。而領域專家要充當開發人員與其他領域專家之間的翻譯。
這些翻譯使模型概念變得混淆，而這會導致有害的代碼重構。這種間接的溝通掩蓋了分裂的形成——不同的團隊成員使用不同的術語而尚不自知。
由於軟件各個部分不能夠渾然一體，因此這就導致無法開發出可靠的軟件。翻譯工作導致各類促進深入理解的知識和想法無法結合在一起。
不同語言產生的後果
如果語言支離破碎，項目必將遭遇嚴重的問題。領域專家使用他們自己的術語，而技術團隊使用的語言則經過調整，以便從設計角度討論領域。
日常討論所使用的術語與代碼中使用的術語不一致。甚至同一個人在講話和寫東西時使用的語言也不一致，這導致的後果是，對領域的深刻表述常常稍縱即逝，根本無法記錄到代碼或者文檔 中。
翻譯使得溝通不暢，並削弱了知識消化。 然而任何一方的語言都不能成爲公共語言，因爲它們無法滿足所有的需求。
讓領域模型成爲公共語言
所有的程序的開銷，連帶着誤解的風險，成本實在太高了。項目需要一種公共語言，這種語言要比所有的語言的最小公分母健壯得多。通過團隊的一致努力，領域模型可以成爲這種公共語言的核心，同時將團隊溝通與軟件實現緊密聯繫在一起。該語言將存在於團隊工作中的方方面面。
最小公分母： 就是兩個分母的最小公倍數,比如說2和3的最小公倍數是6,那麼最小公分母就是6。
通用語言的詞彙
通用語言的詞彙包括類和主要的操作名稱。語言中的術語，有些是用來討論模型中已經明確的規則，還有些則來自施加於模型的的高級組織原則如：限界上下文、上下文映射圖。
基於模型的語言
開發人員應該使用基於模型的語言來描述系統中的工件、任務和功能。這個模型應該爲開發人員和領域專家提供一種用於相互交流的語言，而且領域專家還應該使用這種語言來討論需求、開發計劃和特性。語言使用得越普遍，理解進行得就越順暢。
將模型作爲語言的支柱。確保團隊在內部的所有交流中以及代碼中堅持使用這種語言，在畫圖、寫東西、特別是講話時也要使用這種語言。
領域專家應該抵制不合適或無法充分表達領域理解的術語或結構，開發人員應該密切關注那些將會妨礙設計的有歧義和不一致的地方 。
總結
在DDD的世界裏，不管是作爲領域專業還是開發人員，大家在討論業務的時候都應該使用雙方都能理解的語言。儘管在初期這種語言是晦澀難懂的，但隨着項目的發展會慢慢漸入佳境。
空有通用語言其實不夠，使用口頭交流的方式，容易造成知識的丟失，也不利於項目未來的發展。應當建立模型，所有的討論都是基於模型的，任何的的變更都要反映到模型上面。