# 第2章 交流與語言的使用

## 模式 Ubiquitous Language

首先寫下一個小句子，
然後將它分成小段;
再將它們打亂並重新排列
彷彿是巧合一般：
短句的順序
對意思完全沒有影響。

-Lewis Carroll

我們/今天/要/開發/一個/POS系統
POS系統/今天/我們/要/開發
開發/POS系統/今天/我們/要

**領域專家: 針對要開發的程式部分的知識有深刻的理解
技術團隊: 將所提出來的需求轉化成實際運作的人**

大家在溝通上面都會使用自己熟悉的語言，所以如果大家都依照原本的語言去做溝通，
會導致無法將重要的領域知識給記錄下來，增加了成本，但是沒有一邊的語言是可以讓大家一起使用的。

作者講述需要開發人員以『模型為基礎的語言』來描述作品任務及功能，領域專家可以使用這種語言來討論『需求、開發計劃和特性』。

**要以模型為語言的支柱。確保所有人溝通中都使用了模型，讓大家對同一個東西的認知是一樣的。**

以下為一個例子

場景1:

User: 那我們今天要針對一個核銷系統增加一個新的規則

Dev: 要增加的規則會是怎麼樣的？

User: 我們需要在使用者方案到期後的七天後進行核銷，

Dev: 但是使用者的方案上面有什麼樣的限制嗎？這個使用者是場館使用者還是平台使用者？

User: 使用者可以核銷的方案是利用線上信用卡購買的方案

Dev：所以我們會需要新增一個新的規則他必須是使用這方案是用線上信用卡購買的，並且在到期後進行核銷。

場景2:

User: 那我們今天要針對一個核銷系統增加一個新的規則

Dev: 那我們針對VerificaitonSystm新增的一個VerificationRule的時候，他會有怎麼樣的限制

User: 他的VerificationRule需要針對MemberContract的ExpireDate 大於 7 的時候核銷。

Dev: 但是MemberContract的類型上有什麼樣的限制嗎？

User: MemberContract的Payment必須要CreditCard.

## 大聲的建模

作者認為改善模型的最佳方式可以透過提出來討論可能的模行變化中個各種結構，
不斷地去優化，
要利用系統性分析和設計的分析能力和對程式碼的感覺去做互補。
並在模型允許的方式底話不斷地去將大家的概念結合再一起，
找到更簡單的說話方式。

**先確定模型的規範後，就不斷的討論讓大家不過的去優化模型跟行為，到最後可以更加簡潔表達。**

## 一個團隊，一種語言

技術人員常會覺得業務參與領域模型，因為覺得他們不懂。

但是如果連領域專家都看不懂你的模型的時候，他是一定是有問題的，
所以當一起討論的時候很快就會發現哪邊跟領域專家想的不一樣就可以去修正，
而領域專家因為模型語言的精確，
很快就可以發現他們自己哪邊的想法是矛盾的或是不夠明確。
最後也許可以直接用模型語言來撰寫驗收測試。

**開發人員跟領域專家在溝通上面一定會有很多術語是不同的，但是透過討論後就可以區別出哪些事各個領域專有的，但是如果是共有的術語，應該是變成是兩邊都是用一樣的術語去識別。**


## 文件與圖

如果人們只靠ＵＭＬ來表示整個模型或設計時，會因為過細而造成困擾，
而ＵＭＬ無法表達的兩個最重要的部分是：模型所表示的概念、物件應該做哪些事情，
但是如果只是把它當作圖的話就沒有這些問題，
我們在用其他的文字語言去做補充，
而讓圖只保留在簡單及物件模型的重要概念這樣子，
模型並不是圖而是幫助我們理解和表達使用，
他的細節應該要顯示在程式碼中。

**把ＵＭＬ拿來當做簡易溝通用的圖像，讓我們大家便於討論，所以就不要把太多的東西放在上面，如果有需要描述的東西可以用語言補充在上面。**

## 書面設計文件

### 文件應該作為程式碼與口頭交流的補充

如果要在程式碼中間表達出所有的細節而不依靠文件的話，會有些遺漏，但是文件不應該要再重複描述已經明確在程式碼中間表達的內容

### 文件應當鮮活並保持最新

作者在寫模型文件的時候會把文件放在模型的附近，
文件最大的用途就是解釋模型的概念，
幫助我們找到大方向，
另外他必須要深入到各種專案活動中，
觀察大家是否有持續在使用它，
如果是大家都已經不討論他就可以將他移到歷史文件，
之後有需要再拿出來使用。

**將文件減到最少，只利用它來作為模型的補充知識，這樣不用一直維護他導致不符合預期。**

##### 極限程式設計

https://zh.wikipedia.org/wiki/%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B
https://blog.toright.com/posts/697/%E6%A5%B5%E9%99%90%E9%96%8B%E7%99%BC-extreme-programming-xp.html

## 完全依賴可執行程式碼的情況

優秀的程式碼有很強的表達能力，
但是他的名字不一定跟他的行為一致，
也要靠開發人員的自律，
所以如果要完全參考的話，
也要在每次異動後判斷命名及更名，
如果程式設計師取的命名很模糊就也會是場災難。

funciton getOneBooking(id){
    app(Booking::class)->find(id);
}

funciton getBooking(id){
    if(!is_array($id)){
        $id = [$id];
    }
    app(Booking::class)->get(id);
}

## 解釋型模型

利用一個不是避免是ＵＭＬ的圖，
利用他的自由度去補充跟更好的去表達使用者的意圖。