建立共同語言
這章主是在講述語言的重要性，而語言又如何直接間接的影響到系統的成敗。這邊的語言並非指程式語言，而是指在相同情境下大家所共同理解的語言，就用 User 這個詞來舉例，在不同情境下就可能代表著不同意義
- 對購物網站而言 : User 可能代表的是逛商城的消費者
- 對商城平台而言 : User 可能代表是進駐的廠商
- 對商城後台而言 : User 可能代表的是進駐廠商的員工
一個 User 在各個情境下代表著不同意義，想關注的事情也不盡相同，當我們沒有情境為背景下，單單用 User 做為溝通可能會陷入雞同鴨講的狀況，這就是情境之於語言為何重要的地方。
過去開會時發現一個現象，時常開發單位與需求單位在溝通時，彼此對於同一個東西用的詞是完全不同的，當需求單位在描述事情時，較新進或對 Domain 不熟的開發人員可能會弄不清楚對方在說什麼，這時候就需要熟的人在旁邊補充「他指的是系統裡的 xxx」，而會產生這樣的差距，常常是因為開發人員將他們的工作視為”將需求翻譯成程式語言”，所以程式內的語言可能自成一格，並與現實用語脫鉤，而這類的情況一多，當不同背景的人共同溝通時就會需要彼此一直翻譯，翻譯的狀況越多，中間遺失掉的”知識”可能就越多，大家應該都有看過翻譯很爛的書的經驗吧…
所以書中建議為不同背景的人找尋共同用語相當重要，這可以減少溝通時因為翻譯而導致的落差，書中舉了一個很真實的案例：當使用者在廣告系統中發佈 (publish) 廣告時，為了避免帶有惡意或不適當的內容，會讓該廣告進入審核的流程 ….，而當這個需求轉化為程式語言後可能會變成
- 當使用者按下 publish 按鈕時，將廣告狀態更新為 Published，並且發出
廣告狀態已變更(AdStatusUpdated)的事件 - 審核系統收到
廣告狀態已變更(AdStatusUpdated)事件時將廣告撈出來排入審核流程
看出這中間有多大的落差了嗎？我們在系統中不用 廣告已被發佈(AdPublished)，取而代之的是廣告狀態已變更（AdStatusUpdated），發佈的動作轉化成狀態的變更，需求在這大量轉化為系統程式碼的過程中，很有可能原始的意圖早已消失，而這可能正是關鍵知識遺失的過程。
精準需求的迷失
每當我們交付功能給客戶，面對客戶的不滿意時，常常歸因於需求描述的失準，開發團隊內會互相抱怨、指責，開發者埋怨開需求的人規格亂寫，開需求的人埋怨開發者搞不清楚也不問，導致開發出來的系統與最終想解決的問題有一大段落差，所以團隊可能會開始找更厲害的 PO 或 PM，開始要求規格書的格式，試圖用鉅細彌遺厚厚一本的規格書來彌補與真實之間的落差。
而事實真的是這樣嗎？很多時候開發人員是沒有機會直接面對需求單位或業務人員的，所以當這些需求單位透過與系統分析師描述後，再透過系統分析師的理解轉化成規格書，這中間可能就已經遺失了一部分真實。
很多時候會議內所謂的共識，是你以為你的共識，我以為我的共識，實際上彼此認知的事情根本不是一回事，等雙方都告一段落後回來一對才發現跟當時說的不一樣，但彼此都覺得自己是照當時的決議實作的啊，所以問題可能不是雙方背信，而是彼此認知根本不在同一個點上。
書中提到可以嘗試在溝通中，用視覺化的方式彌平彼此認知的落差，而我自己的經驗也發現，大量的文字描述常常聽者很難聚焦，當開始把各個會議中談到的東西視覺化，輔助上依賴關係與線性流程，有助於幫助與會人員更能聚焦在同一個點上。
圖片來源: 領域驅動設計與 .Net Core 書中 p.26
透過新的術語發現新的情境
最前面提到在不同情境下，User 可能代表的意義完全不同，當我們在討論過程中可能會脫口而出前台的消費者、平台的廠商、後台的管理者…等等，而當這些用語的不同時，其實也幫助了我們發現了新的情境，針對這些新出現的情境建立對應的模型是需要的，對比於前面只用 使用者(User)來描述，後者更精準也更貼近真實，這也可以避免開發者寫出近乎於上帝類別的 User 來。
雖然短短一小篇，但發現要把讀完的東西用自己的話再說一次真的還有一段差距啊