需求發(fā)生的『良性』『顯性』的變化就是軟件不斷迭代的驅(qū)動力别智，因此我們積累的領(lǐng)域知識和模型也要適應(yīng)這種變化燃逻。關(guān)于提煉知識和建模葱色，Eric Evans 也總結(jié)了一套名為*模型探討漩渦（https://www.domainlanguage.com/ddd/whirlpool/）的方法祟霍。
聚焦于問題域的難點哼凯，領(lǐng)域?qū)＜矣脤嵗ㄒ幌盗胁襟E或者狀態(tài)變化）對場景進行解釋褒翰，與此同時贮懈，團隊開始提煉模型或是審視當(dāng)前模型是否可以解決這些問題；不斷用領(lǐng)域?qū)＜颐枋龅母鄨鼍皝頇z驗?zāi)Ｐ偷挠行杂叛担浑S時將有助于揭示場景的模型場景和模型一并記錄成文檔朵你，不斷進行修正；當(dāng)團隊獲得了對問題域的理解揣非，并設(shè)計了足夠的模型后抡医，應(yīng)該用原型或是實驗代碼來對模型進行驗證。
搞清楚業(yè)務(wù)變化的具體的探索模型（建模）的方式有許多早敬，例如事件風(fēng)暴工作坊（Event Storming）忌傻、用戶故事地圖（Story Mapping）大脉、實例化需求（Specification By Example）。關(guān)于這些方法的綜合運用水孩，可以參考《DDD 15 年》中的一片總結(jié)《模型探索漩渦》（https://zhuanlan.zhihu.com/p/141804228）镰矿。這里不再贅述。
Eric Evans 強調(diào)建模漩渦并不是一種開發(fā)流程俘种，卻能夠適用于各種迭代開發(fā)流程秤标。無論是在軟件開發(fā)生命周期的那個階段，任何時候只要是模型出現(xiàn)問題宙刘，就應(yīng)該跳轉(zhuǎn)到建模的漩渦方法提煉領(lǐng)域知識抛杨。
無獨有偶，在Eric Evans 提出 DDD 的同時期荐类，另一種流行的軟件開發(fā)方法論 RUP （https://en.wikipedia.org/wiki/Rational_Unified_Process）也特別強調(diào)迭代建模。RUP 將軟件生命周期分為四個階段：
構(gòu)思階段 ：包括用戶溝通和計劃活動兩個方面茁帽，強調(diào)定義和細化用例玉罐，并將其作為主要模型。
細化階段：包括用戶溝通和建呐瞬Γ活動吊输，重點是創(chuàng)建分析和設(shè)計模型，強調(diào)類的定義和體系結(jié)構(gòu)的表示铁追。
構(gòu)建階段：將設(shè)計轉(zhuǎn)化為實現(xiàn)季蚂，并進行集成和測試。
移交階段：將產(chǎn)品發(fā)布給用戶進行測試評價琅束，并收集用戶的意見扭屁，之后再次進行迭代修改產(chǎn)品使之完善。
聽起來有些像傳統(tǒng)的瀑布式軟件開發(fā)方法涩禀，但是 RUP 的每個階段也劃分成了更小的迭代料滥。而且我們可以看到，業(yè)務(wù)建模始終貫穿了其生命周期的四個階段艾船。
作為一種厚重的軟件開發(fā)方法論葵腹，RUP 如今已不再流行，但是迭代建模的思想依然值得我們借鑒屿岂。我們應(yīng)當(dāng)抓住軟件開發(fā)生命周期中任何和領(lǐng)域?qū)＜医涣鞯臋C會践宴，通過挑戰(zhàn)和澄清，不斷地完善領(lǐng)域知識和模型爷怀。
到現(xiàn)在為止阻肩，似乎探索模型的實踐大部分和梳理需求的實踐雷同（除了實踐風(fēng)暴工作坊），好像我們在梳理需求的同時就完善了領(lǐng)域模型（當(dāng)然更新模型的可視化需要花費額外的時間）霉撵。但我們可能忽視了一個問題磺浙，如何保證代碼實現(xiàn)也隨著領(lǐng)域模型的完善而演進洪囤。在 Eric 的模型探索階段中有提到用實驗代碼來驗證模型，當(dāng)代碼能夠和模型匹配上撕氧，自然應(yīng)該進入代碼倉庫瘤缩。除此之外還有其他的實踐嗎？
迭代建模是對現(xiàn)有模型的刷新伦泥，而模型最為關(guān)鍵的兩個要素是領(lǐng)域?qū)ο蠛瓦吔绨 ｎI(lǐng)域?qū)ο蠖汲袚?dān)著業(yè)務(wù)上的職責(zé)，必須有明確的描述不脯；而邊界體現(xiàn)著高內(nèi)聚低耦合（不同粒度的邊界府怯，內(nèi)聚的原則不同），邊界內(nèi)外的依賴有著不一樣的約束防楷。描述職責(zé)和約束依賴應(yīng)該是代碼對領(lǐng)域模型的最佳體現(xiàn)牺丙。
