無論有沒有軟體支援, 無論軟體是好是壞, 世界各地每個領域每天都發生著數以億計可以理解的業務
領域驅動設計是一種設計方法, 試**決的問題是軟體的難以理解, 難以演化. 採用的方法是圍繞業務概念來構建模型.
不過你也可以從兩個角度來理解領域驅動設計: 作為設計結果的ddd和作為開發方法的ddd, 即 what and how.
作為結果的領域驅動設計是這樣一種設計(what): 它建立了乙個模型, 這個模型具有以下一些特徵:
這樣的模型很容易隨著業務的變化而變化, 至少不應該比業務本身的變化更困難, 更劇烈. 保守一點講, 業務領域的變化比技術領域的變化緩慢的多, 模型反映業務, 因此也穩定的多. 當業務漸變時, 模型只需跟隨做簡單的調整.
業務其實並不複雜, 無論有沒有軟體支援, 每個領域每天都實際發生著數以億計的從財務的角度可以追溯的,從從業人員的角度可以理解的, 從管理者的角度可以掌控的業務. 軟體卻難以正確表達的原因不在於業務本身多複雜, 而在於我們用的工具, 用的方法. ddd試圖分離實現(solution domain)的複雜性, 還原業務(problem domain)的簡單性, 並提供了相應的工具和方法支援.
這個模型描繪的前景是激動人心的, 但是如何實現 (how)? 我們需要實現技術的支援和開發過程實踐的支援
書裡描述了一些通用的構造塊(building block), 即實現技術的支援:
當然這些構造塊並不是全部, 新的模式會不斷被開發出來 彌合分析與設計及實現之間的gap.這些構造塊也不是必需的. 雖然eric在書裡說設計必須考慮實現, 但實現並不非得就是書裡提供的構造塊, 比如 entity, value object, repository. 反過來說也可以: 用了entity, value object, repository等並不一定意味著你就是在進行ddd. 事實上, 類似entity和value object這樣的基本概念上的區別, side effect free function這樣的常識, 是任何一種設計, 任何一種設計方法都應該考慮的.
而更重要的是, 開發過程中哪些實踐可以支援ddd的實現? 事實上這一部分是ddd的核心, 甚至你可以把它理解為what而不是how. 因此描述可以反過來: 我們無法保證最終能得出乙個完美的領域模型, 我們只能在開發過程中盡力去改進我們手頭的模型, 然後順其自然. 因此如何改進模型才是關鍵, ddd提供了一些基本的方法來促成這種改進.
然而我們通常面臨更多的現實約束, 比如我們不是每次都是從頭開始建造乙個新的系統, 我們不得不與遺留系統進行整合; 也不是只有我們乙個開發團隊, 我們需要與其他團隊合作. eric將解決這部分問題的方法叫做戰略性設計(strategic design)
這確實是最困難的一部分, 如果在戰略上選擇了不合適的方向, 則前面的構造塊, 領域模型只能算是區域性優化. taowen說ddd這本書只看第四部分就可以了, 這也是一種distill core domain吧.
領域驅動設計系列（一） 為何要領域驅動設計？
領域驅動設計最近貌似開始火起來了，越來越多的人開始認識到領域設計的重要性，從我做過的專案來看，似乎歐洲已經有很多的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，但是網上不管是文章還是 都顯得太過 高大上 一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小...
領域驅動設計之我見 領域業務
談到領域驅動設計 ddd 人們很容易想到如下這張圖，那麼是不是你的軟體做了如下的分層設計就是領域驅動設計的了？顯然不是，以下分層只能說明的軟體做了分層架構，領域驅動設計的核心在領域模型，領域模型的核心在業務知識。如果能夠採用物件導向思維將業務抽象為恰當的模型，不管用什麼架構都稱得上領域驅動設計。在大...
領域驅動設計 Copyright
版權 許多標誌被生產商和銷售商用於辨別他們的產品像商標一樣被要求權利。那些標誌出現在本書的某些地方，或者addison wesley已經意識到商標權利，這些標誌已經被印刷成首字母大寫或者全部大寫。作者和出版商儘管已經小心準備此書，但是沒有表達或者隱含的擔保任何性質的錯誤和忽略並擔負相關責任。沒有義務...