在傳統的瀑布方法中，業務專家與分析員進行討論，分析員消化理解這些知識後，對其進行抽象並將結果傳遞給程式設計師，再由程式設計師編寫軟體**。由於這種方法完全沒有反饋，因此總是失敗。分析員全權負責建立模型，但他們建立的模型只是基於業務專家的意見。他們既沒有向程式設計師學習的機會，也得不到早期軟體版本的經驗。知識只是朝乙個方向流動，而且不會累積。
有些專案使用了迭代過程，但由於沒有對知識進行抽象而無法建立起知識體系。開發人員聽專家們描述某項所需的特性，然後開始構建它。他們將結果展示給專家，並詢問接下來做什麼。 如果程式設計師願意進行重構，則能夠保持軟體足夠整潔，以便繼續擴充套件它;但如果程式設計師對領域不感興趣，則他們只會了解程式應該執行的功能，而不去了解它背後的原理。雖然這樣也能開發出可用的軟體，但專案永遠也不會從原有特性中自然地擴充套件出強大的新特性。
好的程式設計師會自然而然地抽象並開發出乙個可以完成更多工作的模型。但如果在建模時只是技術人員唱獨角戲，而沒有領域專家的協作，那麼得到的概念將是很幼稚的。使用這些膚淺知識開發出來的軟體只能做基本工作，而無法充分反映出領域專家的思考方式。
在團隊所有成員一起消化理解模型的過程中，他們之間的互動也會發生變化。領域模型的不斷精化迫使開發人員學習重要的業務原理，而不是機械地進行功能開發。領域專家被迫提煉自己已知道的重要知識的過程往往也是完善其自身理解的過程，而且他們會漸漸理解軟體專案所必需的概念嚴謹性。
所有這些因素都促使團隊成員成為更合格的知識消化者。他們對知識去粗取精。他們將模型重塑為更有用的形式。由於分析員和程式設計師將自己的知識輸入到了模型中，因此模型的組織更嚴密，抽象也更為整潔，從而為實現提供了更大支援。同時，由於領域專家也將他們的知識 輸入到了模型中，因此模型反映了業務的深層次知識，而且真正的業務原則得以抽象。
模型在不斷改進的同時，也成為組織專案資訊流的工具。模型聚焦於需求分析。它與程式設計和 設計緊密互動。它通過良性迴圈加深團隊成員對領域的理解，使他們更透徹地理解模型，並對其 進一步精化。模型永遠都不會是完美的，因為它是乙個不斷演化完善的過程。模型對理解領域必須是切實可用的。它們必須非常精確，以便使應用程式易於實現和理解。
團隊成員、開發人員和領域專家等都學到了知識，他們開始使用一種公共的語言，而且形成了貫穿整個實現過程的反饋閉環。
知識消化是一種探索，它永無止境。
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd？1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...