在傳統的瀑布方法中，業務專家與分析員進行討論，分析員消化理解這些知識后，對其進行抽象并將結果傳遞給程式員，再由程式員撰寫軟體代碼，由于這種方法完全沒有反饋，因此總是失敗，分析員全權負責創建模型，但他們創建的模型只是基于業務專家的意見，他們既沒有向程式員學習的機會，也得不到早期軟體版本的經驗，知識只是朝一個方向流動，而且不會累積，
有些專案使用了迭代程序，但由于沒有對知識進行抽象而無法建立起知識體系，開發人員聽專家們描述某項所需的特性，然后開始構建它，他們將結果展示給專家，并詢問接下來做什么， 如果程式員愿意進行重構，則能夠保持軟體足夠整潔，以便繼續擴展它;但如果程式員對領域不感興趣，則他們只會了解程式應該執行的功能，而不去了解它背后的原理，雖然這樣也能開發出可用的軟體，但專案永遠也不會從原有特性中自然地擴展出強大的新特性，
好的程式員會自然而然地抽象并開發出一個可以完成更多作業的模型，但如果在建模時只是技術人員唱獨角戲，而沒有領域專家的協作，那么得到的概念將是很幼稚的，使用這些膚淺知識開發出來的軟體只能做基本作業，而無法充分反映出領域專家的思考方式，
在團隊所有成員一起消化理解模型的程序中，他們之間的互動也會發生變化，領域模型的不斷精化迫使開發人員學習重要的業務原理，而不是機械地進行功能開發，領域專家被迫提煉自己已知道的重要知識的程序往往也是完善其自身理解的程序，而且他們會漸漸理解軟體專案所必需的概念嚴謹性，
所有這些因素都促使團隊成員成為更合格的知識消化者，他們對知識去粗取精，他們將模型重塑為更有用的形式，由于分析員和程式員將自己的知識輸入到了模型中，因此模型的組織更嚴密，抽象也更為整潔，從而為實作提供了更大支持，同時，由于領域專家也將他們的知識 輸入到了模型中，因此模型反映了業務的深層次知識，而且真正的業務原則得以抽象，
模型在不斷改進的同時，也成為組織專案資訊流的工具，模型聚焦于需求分析，它與編程和 設計緊密互動，它通過良性回圈加深團隊成員對領域的理解，使他們更透徹地理解模型，并對其 進一步精化，模型永遠都不會是完美的，因為它是一個不斷演化完善的程序，模型對理解領域必須是切實可用的，它們必須非常精確，以便使應用程式易于實作和理解，
團隊成員、開發人員和領域專家等都學到了知識，他們開始使用一種公共的語言，而且形成了貫穿整個實作程序的反饋倍訓，
知識消化是一種探索，它永無止境，
DDD開源框架xtoon-boot下載：https://gitee.com/xtoon/xtoon-boot
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/267490.html
標籤：其他
上一篇：對于程式員CPU是什么
下一篇：搞笑，我是認真的！