非原創,感謝《領域驅動設計》這本書框架
模型被用來描繪人們所關注的現實或想法的某個方面。模型是一種簡化。是對現實的解釋——把與解決問題密切相關的方面抽象出來,而忽略無關的細節。工具
每一個軟件程序是爲了執行用戶的某項活動,或是知足用戶的某種需求。這些用戶應用軟件的問題區域就是軟件的領域。一些領域涉及物質世界,例如,機票預訂程序的領域中包括飛機乘客在內。有些領域則是無形的,例如,會計程序的金融領域。軟件領域通常與計算機關係不大,固然也有例外,例如,源代碼控制系統的領域就是軟件開發自己。翻譯
(技術或者軟件是用來實現業務所要的功能或者解決業務計算遇到的瓶頸問題)設計
爲了建立真正能爲用戶活動所用的軟件,開發團隊必須運用一整套與這些活動有關的知識體系。所需知識的廣度可能使人望而生畏,龐大而複雜的信息也可能超乎想象。模型正是解決此類信息超載問題的工具。模型這種知識形式對知識進行了選擇性的簡化和有意的結構化。適當的模型可使人理解信息的意義,並專一於問題。開發
(我的理解:若是遇到要對一個龐大複雜的業務作系統開發,所須要的知識體系很是大,這個時候可使用一些抽象的模型或者方法,更好的理清業務邏輯,造成軟件系統,有些人爲何業務設計能力那麼厲害,就是由於抽象思惟能力很強)產品
領域模型並不是某種特殊的圖,而是這種圖所要傳達的思想。它毫不單單是領域專家頭腦中的知識,而是對這類知識嚴格的組織且有選擇的抽象。圖能夠表示和傳達一種模型,一樣,精心書寫的代碼或文字也能達到一樣的目的。領域建模並非要儘量創建一個符合「現實」的模型。即便是對具體、真實世界中的事物進行建模,所獲得的模型也不過是對事物的一種模擬。它也不僅僅是爲了實現某種目的而構造出來的軟件機制。建模更像是製做電影——出於某種目的而歸納地反映現實。即便是一部紀錄片也不會原封不動地展示真實生活。就如同電影製片人講述故事或闡明觀點時,他們會選擇素材,並以一種特殊方式將它們呈現給觀衆,領域建模人員也會依據模型的做用來選擇具體的模型。class
在領域驅動的設計中,3個基本用途決定了模型的選擇。軟件
(1) 模型和設計的核心互相影響。正是模型與實現之間的緊密聯繫才使模型變得有用,並確保咱們在模型中所進行的分析可以轉化爲最終產品(即一個可運行的程序)。模型與實現之間的這種緊密結合在維護和後續開發期間也會頗有用,由於咱們能夠基於對模型的理解來解釋代碼。技巧
(2) 模型是團隊全部成員使用的通用語言的中樞。因爲模型與實現之間的關聯,開發人員可使用該語言來討論程序。他們能夠在無需翻譯的狀況下與領域專家進行溝通。並且,因爲該語言是基於模型的,所以咱們可藉助天然語言對模型自己進行精化。程序
(3) 模型是濃縮的知識。模型是團隊一致認同的領域知識的組織方式和重要元素的區分方式。透過咱們如何選擇術語、分解概念以及將概念聯繫起來,模型記錄了咱們看待領域的方式。當開發人員和領域專家在將信息組織爲模型時,這一共同的語言(模型)可以促使他們高效地協做。模型與實現之間的緊密結合使來自軟件早期版本的經驗能夠做爲反饋應用到建模過程當中。
軟件的核心是其爲用戶解決領域相關的問題的能力。全部其餘特性,無論有多麼重要,都要服務於這個基本目的。當領域很複雜時,這是一項艱鉅的任務,要求高水平技術人員的共同努力。開發人員必須鑽研領域以獲取業務知識。他們必須磨礪其建模技巧,並精通領域設計。
(我的理解:然而,不少技術開發人員都不會主動去了解業務設計,只關注本身的技術是否獲得提升,我曾經的組員不少都是這樣的思惟,最後致使作東西須要別人來設計框架,講解邏輯,本身使用技術實現,很是片面的認爲寫代碼是技術的所有,認爲掌握不少複雜的業務新知識,而這些新知識對提升計算機的能力並沒有裨益。我認爲,技術人員使用模型來抽象業務邏輯,是很是有必要的。)
開發人員能夠採用一些系統性的思考方法來透徹地理解領域並開發出有效的模型。還有一些設計技巧可使毫無頭緒的軟件應用變得層次分明。掌握這些技能能夠令開發人員的價值倍增,即便是在一個最初不熟悉的領域中也是如此。