# 第1章 消化知識
* 作者描述如何進行PCB 專用軟體的工具的設計

* 
* net 導線

* 
* 物件交換圖(object interaction diagram)
* 加入 signal

* 
* 用net來接腳
* 開始討論特定功能,探針模擬(probe simulation)
* 追蹤信號的傳播,以便檢測在設計中可能出現特定類型問題的位置

* 
* 透過特定的Pin 將信號經由元件推送到其他特定的Pin

* 
* 信號每經過一個Net, 稱為1跳
* 每個元件的推動 行爲都是一樣

* 
* 元件的類型決定了推動行為

* 

> 最後放棄了探測模擬,因為它不是一項重要的開發任務
> 但模型幫助理解"如賀透過元件推動信號,以及如何計算跳數"
>

## 有效建模的要素
1. 模型與實作的綁定( Binding the model and the implementation)
2. 建立了一種以模型為基礎的語言( Cultivating a language based on the model)
3. 開發一個蘊含豐富知識的模型( Developing a knowledge-rich model)
4. 提煉模型( Distilling the model)
5. 腦力激盪和實驗 ( Brainstorming and experimenting)

## 知識消化
* 資訊的原始資料來自
* domain expert
* 現有系統的使用者
* 技術團隊以前在 "相關遺留系統" 或 "同領域的其他專案"

* 傳統 Waterfall 因為沒有回饋所以總是失敗(因為知識只是朝一個方向流動,沒有累積)
* 因為 SA 負責建立 prototype 依據業務專家的意見
* 但 SA沒有向 programmer學習也沒有得到早期版本的經驗

* 有迭代過程的專案
* 透過重構,可以持續保持軟體的簡潔
* 假如programmer沒有去了解"領域"背後的原理,專案不會從"原有的特性"自然地快展出更強大的"新特性"

* 好的Progrmamer 會自然地抽象並開發出一個"可以完成更多工作的模型"
* 在建模時需要技術人員搭配domain expert, 否則只是做基本工作,無法反應domain expert的思考方式

* 模型 在不斷改進時,成為組織專案資訊流的工具

## 持續學習
* 看來沒有技術難度的領域可能是一種錯覺
* 沒有意識到"不知道的東西"有多少,這種無知往往會導致我們做出錯誤的假設
* 無法傳遞知識,例如一些外包的關鍵子系統,只交回程式碼
* 用典型的設計方法時,程式碼和文件不會透過有用形式表示"這些得來不易的知識",大部分透過口頭傳遞知識
* 開發人員同時"增進技術知識","培養一般的領域建模技巧"和"特定領域的知識"
* 擅長自學的團員可以處理為關鍵領域的開發任務
* 領域專家也更清楚了解應用程式的目標
* 早期的知識消化過程,讓團隊成員/開發人員/領域專家
* 開始使用共同語言

## 知識豐富的設計
* 貨櫃航運專案
* 知識消化產生的模型可以反映出對知識深層理解
* 模型改變,開發人員進行重構,反映出模型的變化,知識合併到應用程式
* 領域專家,反覆研究所有規則 / 解決規則之間的矛盾 / 用常識彌補規則的不足

## 深層模型
* 一開始建立可以描述貨物(cargo)和運貨航線(itinerary)的模型
* 領域專家不接受,因為他們有自己考慮業務的方式
* 透過幾個月的知識消化後
* 從"貨櫃在各個地點之間傳輸"改為"貨運責任在各個實體之間傳遞"
* 透過瞭解"作業(operations)"與"責任(responsibilities)"的重要關係而開發

## 參考
* [領域驅動設計：軟體核心複雜度的解決方法 (Domain-Driven Design: Tackling Complexity in the Heart of Software) - 讀書會](https://hackmd.io/nPeeBHuESmeUtOjIif6PBg)
* 持續學習(Kerievsky 2003), Refactoring to Patterns
* https://www.tenlong.com.tw/products/9789861814025
* https://www.tenlong.com.tw/products/9789865021832?list_name=sp