一、設計領域模型的難點：
1.如何提取概念類：
獲取領域模型所需素材通常有兩個途徑：與客戶現場交流中獲得，和在用例的各個流程中提取名詞或名稱短語獲得，這些我們稱之為概念類。
現在的問題是，哪些應當成為領域模型中的概念類呢？如果我引用一堆定義和准則，並不能讓你清楚明了，也許一個生動的比喻更能夠讓你理解深刻。
需求分析有時候就像一部部動畫劇，而那些枯燥乏味的概念，紛繁復雜的流程，在這些動畫劇中似乎都突然活了，個個都有語言有性格。
在這些動畫劇中扮演的所有角色，就是我們需要的概念類。而他們做的所有動作，就是用例模型中的所有流程。
另一個比較撓頭的問題就是，業務領域中的哪些概念應當成為概念類，哪些應對成為概念類中的屬性。
這是一個非常模糊的問題，沒有一個准確的答案。一般來說，如果一個概念記錄的僅僅是一段文字或一個數字，那么它應當作為一個概念類中的某個屬性，否則就應當作為一個概念類。
比如“快遞員送快遞”，這里的“快遞員”、“快遞”都是從中提取的概念類，但是“快遞”中的“地址”呢？這要看你現在分析的這個系統如何去記錄這個“地址”了。
如果記錄的僅僅是一個文本，那么它應當成為“快遞”中的一個“地址”屬性；如果記錄的不僅僅是一個文本，而是精細地記錄了“郵政編碼”、“城市”、“街道”、“通訊地址”等信息，那么它應當成為一個概念類，與“快遞”進行關聯。
除了這些名稱和名稱短語形成的概念類，還有一些相對獨立的行為，作為服務也應當形成概念類。這一類概念類我們可以在需求分析不斷深化的過程中，在以后的迭代中加入到領域模型。
1.如何提取概念類：
獲取領域模型所需素材通常有兩個途徑：與客戶現場交流中獲得，和在用例的各個流程中提取名詞或名稱短語獲得，這些我們稱之為概念類。
現在的問題是，哪些應當成為領域模型中的概念類呢？如果我引用一堆定義和准則，並不能讓你清楚明了，也許一個生動的比喻更能夠讓你理解深刻。
需求分析有時候就像一部部動畫劇，而那些枯燥乏味的概念，紛繁復雜的流程，在這些動畫劇中似乎都突然活了，個個都有語言有性格。
在這些動畫劇中扮演的所有角色，就是我們需要的概念類。而他們做的所有動作，就是用例模型中的所有流程。
另一個比較撓頭的問題就是，業務領域中的哪些概念應當成為概念類，哪些應對成為概念類中的屬性。
這是一個非常模糊的問題，沒有一個准確的答案。一般來說，如果一個概念記錄的僅僅是一段文字或一個數字，那么它應當作為一個概念類中的某個屬性，否則就應當作為一個概念類。
比如“快遞員送快遞”，這里的“快遞員”、“快遞”都是從中提取的概念類，但是“快遞”中的“地址”呢？這要看你現在分析的這個系統如何去記錄這個“地址”了。
如果記錄的僅僅是一個文本，那么它應當成為“快遞”中的一個“地址”屬性；如果記錄的不僅僅是一個文本，而是精細地記錄了“郵政編碼”、“城市”、“街道”、“通訊地址”等信息，那么它應當成為一個概念類，與“快遞”進行關聯。
除了這些名稱和名稱短語形成的概念類，還有一些相對獨立的行為，作為服務也應當形成概念類。這一類概念類我們可以在需求分析不斷深化的過程中，在以后的迭代中加入到領域模型。
2.如何對非真實世界的概念建模
3.如何避免領域模型中的概念類出現二義性。比如在與客戶討論需求的過程中，我們和客戶都使用了一個業務術語，但我們對這個業務術語的理解存在着差異，以致我們花了大量時間來討論一個問題，
卻誰也沒有向對方說明白自己的意思，直到最后我們發現對這個術語理解的偏差。
卻誰也沒有向對方說明白自己的意思，直到最后我們發現對這個術語理解的偏差。
4.如何根據用戶需求挖掘出領域內的相關事物，思考這些事物的本質關聯及其變化規律？
5.對象之間的關聯該如何設計？如何讓關聯盡量少？如何挖掘是否存在關聯的限制條件？如何簡化關聯？
6.如何創建領域實體或值對象，是通過工廠還是直接通過構造函數？
7.如何重構模型？尋找模型中覺得有些疑問或者是蹩腳的地方，考慮對象應該通過關聯導航得到還是應該從倉儲獲取？聚合設計的是否正確？模型的性能怎樣？如何不斷地完善和細化？
二、設計領域模型指導原則：
1.敏捷建模Agile Modeling – 類圖的草圖
（1）是否利用工具建模 創建領域模型的目的是快速地理解關鍵的概念，並在涉眾之間交流。
（2）完美不是目標
（3）是否利用工具，酌情考慮，前期可以使用草圖,后期要用工具建模,因為方便交流。
2.報告性的、或者總結性的對象，是否定義為概念
（1）視情況而定如單據若這是作為其他信息的集合則不作為概念，若單據有特殊角色如作為退貨單據的憑證,則視為概念。
3. 構建領域模型，類似地圖制作
（1） 使用現有的名詞
（2） 剔除掉無關的、或者超出范圍的一些特征
（3） 不需要額外增加沒必要的概念！
4. 如何對非真實世界的概念建模
（1）有些軟件系統着眼於解決領域問題，但是在現實中或者業務中很少有概念與之對應
例如，電信領域“交換機”相關的概念
消息、連接、端口、對話、路由、協議
5.經常容易出錯的選擇：Attributes vs. Classes ，原則：
（1） 如果認為某概念類X不是現實世界中的數字或文本，那么X可能是概念類而不是屬性
（2） 如果符合下列條件，可能是一個類 ：
有很多元素構成
有一些操作、行為
有數量單位
6.對一些描述‘Description’性質的概念建模指導原則：
（1）定義成“描述”類的原則 ：
如果描述內容獨立於對應 的事物 ，如產品、產品 描述
如果刪除對象的同時刪除 了描述，而該描述還需要 繼續維護
為了減少重復或者更清晰
1.敏捷建模Agile Modeling – 類圖的草圖
（1）是否利用工具建模 創建領域模型的目的是快速地理解關鍵的概念，並在涉眾之間交流。
（2）完美不是目標
（3）是否利用工具，酌情考慮，前期可以使用草圖,后期要用工具建模,因為方便交流。
2.報告性的、或者總結性的對象，是否定義為概念
（1）視情況而定如單據若這是作為其他信息的集合則不作為概念，若單據有特殊角色如作為退貨單據的憑證,則視為概念。
3. 構建領域模型，類似地圖制作
（1） 使用現有的名詞
（2） 剔除掉無關的、或者超出范圍的一些特征
（3） 不需要額外增加沒必要的概念！
4. 如何對非真實世界的概念建模
（1）有些軟件系統着眼於解決領域問題，但是在現實中或者業務中很少有概念與之對應
例如，電信領域“交換機”相關的概念
消息、連接、端口、對話、路由、協議
5.經常容易出錯的選擇：Attributes vs. Classes ，原則：
（1） 如果認為某概念類X不是現實世界中的數字或文本，那么X可能是概念類而不是屬性
（2） 如果符合下列條件，可能是一個類 ：
有很多元素構成
有一些操作、行為
有數量單位
6.對一些描述‘Description’性質的概念建模指導原則：
（1）定義成“描述”類的原則 ：
如果描述內容獨立於對應 的事物 ，如產品、產品 描述
如果刪除對象的同時刪除 了描述，而該描述還需要 繼續維護
為了減少重復或者更清晰