最近在做保險行業的ipad客戶端應用，在專案過程中引入了領域模型設計和mvc的設計思想，引發了一番爭論。從實踐過程來看領域建模更多的是一種分析和設計業務模型的一種方法。由於在ios開發中並沒有像j2ee開發企業應用這樣成熟的開發框架，mvc更多的應用在表現層的開發，uiviewcontroller嚴格來劃分應當都屬於view（檢視層），這也不怪蘋果在ios上更多是針對小應用或者遊戲的開發的精簡版。
個人認為不論在實際開發中是否引入領域模型層，都可以採用領域模型來分析業務，而在實際開發中領域模型層和j2ee現在廣泛採用的service層有相似之處。都是對業務邏輯的封裝，service層的引入來自於controller層和貧血型模型層，由於隨著業務邏輯的複雜度提公升，controller除了處理應用邏輯同時處理領域邏輯，造成controller過重，從而將通用的業務邏輯提取出service層作為封裝和復用。貧血的模型從實際開發中更多是基於表的開發模式，從設計庫表作為專案的核心，輔以業務流程圖，最終實現為乙個乙個的service。而領域建模從設計開始不關心資料儲存和表現層，而是將業務模型抽象成一組相互協作的領域類，在類與類之間運用各種物件導向技術，使實際的業務對映成為類與類之間的關係。
在我們的實際開發過程中，大部分的和資料相關的都不是資料庫儲存的，更多的是介面的呼叫。在系統中實現業務邏輯的方法有很多，常用的service＋實體類起到了領域模型是起到同樣的作用的，至於誰好誰壞，我覺得每個人的視角不同，做慣了j2ee的我想更容易接受service＋實體類的模式。
關於領域模型，100個人有101種領域模型，很難說誰的好誰的不好，只存在誰的好用誰的不好用。同時我們看到實際開發過程是乙個除了**，系統架構也在不斷重構的過程。
在客戶端開發過程中使用領域驅動是否大材小用了呢？我覺得乙個領域驅動是一種習慣，一旦掌握了就不太願意採用其他的設計方法，即使它的業務邏輯很簡單。第二，領域建模是一種設計方法，與具體的開發架構沒有必然的聯絡，團隊可以選擇自己熟悉的開發框架來做。
寫的有些亂，全當給自己備案，有機會把實際專案中的設計總結一下。
DDD中的「領域模型」
在網上搜尋領域模型，有大量的文章。一種是 於最初的傳統軟體開發過程，一種 於領域驅動設計 ddd 在傳統軟體開發中，軟體設計師通常使用uml語言進行系統建模，裡面也在強調領域模型的重要性，這兩者很容易混淆。我給大家找到了一些資料，先來看看傳統軟體開發中，領域模型是什麼。領域模型是什麼？理論派觀點 實...
DDD 領域驅動設計 領域模型中的使用者設計
驗證 根據 userid 判斷此使用者是否擁有部落格。許可權 根據當前 loginname，判斷此使用者是否擁有審核許可權。public int userid public string userloginname public string userdisplayname public strin...
（原創）領域模型中貧血模型與充血模型的簡單區別
目錄 一 領域模型 二 區分 1.貧血模型 2.充血模型 領域模型 domain model 是對現實世界中物件的表示，又稱為領域物件模型 概念模型 業務實體，它通常都具有目標物件的特徵和行為，當多個領域模型結合在一起時，就可以完成各種業務邏輯，其實也是對現實世界中物件之間關聯關係的一種還原。這裡主...