領域驅動設計的廣泛評價是個好東西，也有評價把問題搞複雜了的，大家有目共睹，我就不發表看法了，我只針對其中值得學習的方面進行研究，結合自己的實踐來得出總結。在我繞了一大圈之後回來發現，其實領域驅動設計真正有價值的東西，就是這個領域建模。然而網上基本是架構實踐的東西，卻很少有建模肝物，這就導致除此接觸ddd的人很難看全乙個整體，見尾不見首。我等有時間再整理有關建模的內容。
如果開發過三層架構，對於ddd的經典4層一般人都很容易理解，關鍵難點在於把握其目的性，4層因何而來，聚合、實體、值物件因何而來，始終沒有乙個貫穿前後的說法，甚至被認為用了ddd就應該這麼分這麼幹。
當我看了一些例子，我開始懵逼，開始不理解，我就會想到以下問題：
底要解決什麼問題？
問題有沒有得到解決，效果是否讓人滿意？
為什麼要這麼幹？
這種做法來自於**，由什麼來指導？
這種做法能形成統一觀點嗎？
那有什麼依據要這麼做？
你能接收這種做法嗎？
經過這一系列的反思，在那些看似合情合理卻又無從理解如何下手的例子中，我找到了弊端，都是慣性思維在作怪，在這些所謂的實踐例子中，嚴謹程度並不高，當中缺失了很多定位和過程內容，根據作者的思路跳躍性的開展，篇幅很大，坑卻很多，讓大多數人覺得（也包括本人）認為，乙個完整的套路就是如此，殊不知建模這個步驟並不是一腦袋一拍一步到位的。
例如軟體的開發模型——瀑布模型，或者v型，都明確指明了每乙個階段所創造的內容以提供給下一階段，使用者需求-->需求分析-->系統設計-->其他各種文件。領域建模是有多個環節組成，每個環節都能夠為下乙個環節提供必需的清單。根據我的整理，通常的流程如下：
1、主要業務流程圖
2、角色劃分圖及其說明（根據1列出所有角色及其關係結構）
3、用例圖（根據2得到每個角色的用例）
4、領域個體圖（根據1、3得到乙個個單個的領域物件，同時產出領域邊界描述，但是此時的邊界描述可能還是模糊的，在後續每個步驟都會得到細化）
5、領域關係圖（根據2、4得到領域之間的相互依賴，劃分出核心領域）
6、角色-通用領域圖（根據2、5將角色加進來，劃分出通用領域）
7、四色原型①（只需要role-mi屬性關係圖，將6中的角色和領域逐個對應，產出服務、角色屬性）
8、四色原型②（根據7加入ppt，將6中的角色歸類合併，對應得到ppt對應的實體、屬性、值物件）
9、針對7、8一致性、併發性、事件要求等說明
10、倉儲、應用、服務、模式
11、其他落地過程（資料庫設計、併發、訊息、介面、適配、架構等等......）
任何乙個不規定每乙個環節的必需品和產出物的開發過程，都是耍流氓。
有的給出聚合模型，但是流程圖、用例圖，產出物和必需品隻字不提。
有的將領域圖直接當做流程圖使用，或者反過來。
有的給出的領域圖都是草圖，非常不嚴謹。
有的從流程圖直接跳到類圖聚合，雖然提到領域，但是沒看到任何轉化過程。
有的具備了詳細的領域**，講了一大堆概念，但是接下來何去何從、如何接應，沒有然後。
人就是這樣，總是質疑商店賣假酒，卻從不想酒為什麼是假的。如果你還不能脫離那種動不動就來句show me the code，那麼你的思維還是停留在程式設計師階段，而不能算開發人員。路是走出來的，模式是總結出來的，思想是靠變通出來的。數一數拌過的坎，爬過的坑，幸甚至哉。
《領域驅動設計 軟體複雜核心應對之道》這書中，大量的篇幅都用來闡述模型，並圍繞著建模、分離、重構展開。我認為，領域驅動設計就是一種建模學說，它所主導的方式就是從面向業務領域的層面開始思考、分析、建模，它的範圍是一種思想、一套概念，因此沒有提供任何實現方式。換而言之，就是將以往直接從業務用例中提煉物件的方式，上公升到將業務作為物件的層面，其本質還是基於物件導向的，區別在於面向的粒度和高度都更廣更高。
不要為了模式而模式，四人幫《設計模式》曾告訴過我們，當你為了解決某個問題而想到了乙個套路，產生一種模式那是再自然不過的事情了，當遇到類似的問題或場景，不應該想「怎麼用」，而是應該想「考慮用」來用應對之。否則就是生搬硬套，何來快感？解決問題能力很強的人不在少數，但是思維變通能力很好的人卻不多。解析和討論，有時候需要保證思路不越界，有時候也需要適當的躍遷，我們的討論或文章，大多都沒能維持這一點，總有一種習慣：能用的都要用上，能扯上關係都要談及，唯恐顯得知識面不夠寬廣，唯恐顯得肉餡還不夠多。《設計模式解析》，他們能在乙個問題範圍內緊咬著思路，做出質量很高的解析，領域驅動設計雖然不是上古時期的產物，但是在九十年代能夠給出乙個當時沒法落地的顛覆性的設計理論，也是前無古人了。
鄧麗君的領域建模
建模競賽題第2賽季第22輪 請根據以下資訊畫出系統的分析類圖。6分 所有回答者都可以得分。總分數根據時間和答案質量綜合評定，回答時間靠後的分數打折扣，折扣係數0.05。舉例 第乙個答，答案質量得分4分，總分4分 第5個答，答案質量得分5分，總分5 1 5 1 0.05 4分。如果有人喜歡一首歌曲，他...
領域建模的重要性 徵集領域建模業務型別
領域建模是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。領域驅動設計分為兩個階段 1.以一種領域專家 設計人員 開發人員都能理解的 通用語言 作為相互交流的工具，在不斷交流的過程...
檔案系統的業務領域建模
領域模型是什麼 領域模型，又稱概念模型 領域物件模型 分析物件模型，是對領域內的概念類或現實世界中物件的視覺化表示，其將結構的概念和行為的概念結合了起來。在書 uml和模式應用 中，就認為領域模型是需求分析階段的業務模型，是一種業務概念實體的模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並...