2023年07月10日 16:09:00
許多人或許會對我的這種做法提出質疑，不錯，很多的流行書籍都告訴我們，在整理完需求以後，可以提取領域模型。但不管怎麼說，我仍然堅持我自己的做法，原因有n:
書上的知識是教我們思考，不是教我們教條主義的。
說白了，一句話，書可能是對的，也可能是錯的，流行的未必就是對的代名詞。有個笑話曰："感冒也是流行的。"很多方法，在實際中工作得很好，但是，在理論上，就是行不通。也有很多方法，在理論上是可行的，不過，放到現實中，就是行不通。
人的思維過程，不是乙個線性的過程。有時候，我們就是先想到乙個簡單的領域模型，而這個領域模型，就可能是我們開發過程中最重要的突破。我們沒有必要去強調先後："這樣是不行的，你必須先整理出需求文件，然後我再提煉領域模型。"，那麼，當遇到工期緊張而要需要你仿製乙個已有系統的時候，你不用這種需求逆工程，還能用什麼辦法？
領域模型是和需求同時存在的，也如同需求一樣，散落在許多人的頭腦中，但需求文件在書寫的過程中，極容易讓人陷於細節，而領域模型，比較適合抓大放小。
在需求分析過程中，我們已經在不自覺的使用領域模型了。例如，我們在描述乙個需求文件時，會說到"actor開啟乙個訂單，系統顯示其所有可編輯的訂單行"，這裡面就隱含了"訂單"，"訂單行"和它們之間的關聯關係，這是在我們寫需求之間就已經在腦子裡形成的簡單模型。有了這個模型，可以在描寫需求的時候，將領域模型元素做為通用的詞彙表，這樣就不會出現前面寫"訂單"，後面寫"銷售訂單"的現象了。
在實際的應用過程中，這種方法是有效的。我個人的理解，我們在需求分析做了如此多的工作，對於設計和實現人員來講，主要就是為了傳遞乙個統一的領域模型。（當然，對測試人員和介面設計、文件編寫人員來講也是如此，不過除了這個領域模型外，還要傳遞其他的東西）。也就是說，如果乙個需求分析人員，在提交需求文件的同時，把自己書寫文件時，腦中形成的領域模型一起提交，會取得事半功倍的效果。
閒話不多說，讓我們切入正題：
領域模型，當然不隻類，關聯和圖這麼簡單，但這確實也是構成領域模型的最基本元素。同時，也要注意，領域模型是系統的抽象，而不是全部，我們要在此刻建立的領域模型，只是屬於架構檢視的那部分。這也就是28原則中的那20%。
將系統中有價值的類，關聯等提取出來，只是完成了領域建模的50%，剩下的50%，就是基於需求，對領域模型構造塊的重新歸類、和組織。
常採用的做法有：
在專案交流和需求調研過程中，你可以根據領域模型，特化出乙個物件圖，這樣非常有助於跟業務專家的交流，並且極容易在領域模型中發現矛盾甚至錯誤的需求。
需求 需求分析能力之二 引入領域模型
2006年07月10日 16 09 00 許多人或許會對我的這種做法提出質疑，不錯，很多的流行書籍都告訴我們，在整理完需求以後，可以提取領域模型。但不管怎麼說，我仍然堅持我自己的做法，原因有n 書上的知識是教我們思考，不是教我們教條主義的。說白了，一句話，書可能是對的，也可能是錯的，流行的未必就是對...
需求 需求分析能力之二 引入領域模型
2006年07月10日 16 09 00 許多人或許會對我的這種做法提出質疑，不錯，很多的流行書籍都告訴我們，在整理完需求以後，可以提取領域模型。但不管怎麼說，我仍然堅持我自己的做法，原因有n 書上的知識是教我們思考，不是教我們教條主義的。說白了，一句話，書可能是對的，也可能是錯的，流行的未必就是對...
怎樣做需求分析（之二）
撥開需求分析的迷霧 像這樣的對話經常出現在軟體開發的過程中。客戶 專案經理的需求對分析人員來講，像 霧裡看 花 般模糊並令開發者感到困惑。那麼，我們就撥開霧影，分析一下需求的具體內容 業務需求 反映了組織機構或客戶對系統 產品高層次的目標要求，通常在專案定義與範圍文件中予以說明。使用者需求 描述了使...