1：知識消化的過程
知識消化的過程
先給乙個典型的應用需求討論場景。
和業務方不斷**需求，用開發者的角度闡述問題並得到他們的糾正，在這個過程中學習領域相關的術語，然後建立雙方都能接受的表達方式。
在得到雙方認可的核心之後，開始編寫最簡單的原型，沒有持久化沒有介面使用假資料，關注邏輯和實體的關係。然後給需求方演示。
不斷繼續上述過程，最終將得到乙個模型以及和模型緊密一致的核心原型。模型將很多同義詞和語言描述中微小的差別做了統一，並排除了很多個和問題沒有直接關聯的事實。
當有新功能加入的時候，開發人員和領域專家會走查原先的模型，當無法表達某個重要場景的時候則繼續按上述的方式建立新的模型或者修改原有模型，讓模型提現領域知識。而在精化模型的過程中，**也得到了演進。
什麼是知識消化
知識消化的過程，就是從大量資訊中探尋有用部分，不斷嘗試資訊組織形式，努力查詢對大量資訊的表達最有效的簡單檢視，就是這樣的過程。
原始資訊在領域專家和現有使用者的頭腦中、在遺留系統的文件中、在同領域的其他專案中。
資訊的形式也可能是專案文件、已有系統和資料、大量的討論等等。
在知識消化的過程中，開發者被迫學習了重要的有業務原理，而不是進行機械的功能開發；領域專家被迫提煉自己的知識澄清自己的需求和解釋使之更加全面和精準。
開發者和分析員的參與讓模型更加嚴密抽象整潔，而領域專家的參與可以反映深層次的知識，對真正重要的東西做出抽象。這會是乙個良性迴圈。
現階段常見的情況
瀑布開發中：
業務專家和分析員討論，分析員來抽象再將結果傳遞給開發者，開發者編寫程式。只是流動是單向的無反饋的，因此不會有積累和迭代更新。分析員負責建立模型且僅僅基於業務專家的意見，即沒解決程式設計師開發過程的困惑也沒有得到程式開發過程問題的反饋。
某些迭代開發：
沒有對知識的抽象也就無法建立知識體系。開發者僅僅聽取需求完成**，然後展示結果並找出下乙個需求。如果程式設計師對領域知識不感興趣，那麼僅僅會機械的完成功能，而不會理解背後的原理。這樣的開發是無法得到可擴充套件的系統的。
由程式設計師自發完成的建模：
如果沒有領域專家的參與，那麼模型可能會非常幼稚，只能做基本工作，而無法充分反映領域的現狀。這一點在「深層次知識」的小結中會詳述。
持續學習
團隊可能重組拆散，外包出去的關鍵子系統可能只交回**而不包括模型，使用電信的開發方式是可能**和文件並不能很好的傳遞知識，一旦某種原因導致沒有口頭傳遞知識，知識就丟失了。
高效的團隊需要有意識的積累知識並持續學習。
即要完善技術本身，也需要完善建立領域模型積累知識的技能。
早期成果雖然變動很大甚至保留下來的不多，但是早期工作還是很重要的。早期工作啟動了知識消化的過程，使後期工作更加高效；開始使用公共語言方便溝通理解；形成了貫穿專案的反饋閉環。
注：走查，指一種非正式的**評審活動，現在廣泛應用於其他方面，一般指一步一步檢查或分布討論。
2：有效建模的要素
1）模型和現實的繫結
2）建立基於模型的語言。讓所有人在乙個概念體系中討論。
3）豐富的領域知識
4）迭代：新增新概念，移除老概念，慢慢深入領域。
5）頭腦風暴和實驗：語言、草圖、頭腦風暴可以在討論中演示、嘗試、演化、匯集。當團隊走查場景時，口頭表達本身就是對模型的可行性測試。整個過程就是在訓練這個模型本身。
3：深層次的知識
領域知識遠不止名詞和概念，活動和規則也是知識的核心元素。領域專家在解決現實問題時，
有太多的常識、最佳實踐、默契等等來處理問題，所以在表達的時候往往意識不到隱藏資訊的缺失，
也往往意識不到，他們認為簡單的過程其實帶有很多潛在的複雜性。而程式設計師則無從知道這些隱藏資訊，除非真的碰到了並和領域專家一起確認。
書中的乙個好例子：
最簡單的貨櫃預定流程模型中，就是來貨裝滿。程式設計師的角度來看，其實這樣就滿足需要了。但是實際操作中可能出現超賣的情況，因為不是每個預定都最終到場。所以通常是允許超賣一部分的，超賣多少，如果超賣了確實不夠裝那麼怎麼處理。對於領域專家，這些都是常識，但是對於程式設計師則是完全無從知道的資訊。
正是由於領域包含了這樣那樣的隱藏知識，所以軟體專家需要同領域專家一起協同，不斷澄清規則消除矛盾和歧義，並不斷迭代模型本身。同時，由於領域專家不能通過**來了解開發者究竟接收到了什麼資訊，因此開發者也需要用一種統一的預言來溝通，這又回到了模型上。
隨著對領域知識的理解逐步加深，往往會丟棄開始看上去很重要的元素，或者切換他們的角度。
但是，真是因為現實的複雜性，那麼考慮太多之後往往陷入另乙個極端，做過分細緻的設計導致複雜度過大。
第15章將討論如何關注重點並隔離問題使當前問題最小化。
DDD領域驅動設計 知識消化
在傳統的瀑布方法中，業務專家與分析員進行討論，分析員消化理解這些知識後，對其進行抽象並將結果傳遞給程式設計師，再由程式設計師編寫軟體 由於這種方法完全沒有反饋，因此總是失敗。分析員全權負責建立模型，但他們建立的模型只是基於業務專家的意見。他們既沒有向程式設計師學習的機會，也得不到早期軟體版本的經驗。...
讀書筆記 領域驅動設計
領域驅動設計 讀書筆記 領域驅動設計我看了三遍，第一和第三遍是粗看，中間一遍是細看。總體感覺這本書很好，是領域建模的指導書。當看完這本書寫個總結是個任務，所以我準備這樣寫總結，先拋開書本憑經驗和從書本中獲得的知識來寫，然後對照書本來寫。拋開書本來看 領域建模，這個片語包括了三個詞，領域 構 建 模 ...
《領域驅動設計》讀書筆記1
最近看了很多的書，深深感到讀書不寫筆記等於白讀，領域驅動設計是我準備在專案中主推的方 所以自己要先做好功課。第一部分讓領域模型發揮作用 每個模型都代表了我們所感興趣的現實或觀點的某些方面。模型是一種簡化，它對現實進行闡述，只是抽象出與解決手頭問題有關的方面而忽略掉無關的細節問題。所以我們抽象出來模型...