領域：
沒有豐富的領域知識能做出複雜的銀行業業務軟體嗎?沒門。答案永遠是否定的。那麼誰 了解銀行業業務?軟體架構師嗎?不，他只是在使用銀行來保護他的財產安全，並且確保需要 錢的時候能夠取出來;軟體分析師嗎?也不是，他只懂得在已獲取到所有材料的情況下，對一 個給定的主題進行分析;軟體開發人員?別難為他了。那麼還有誰?當然是銀行的從業者了。 銀行業務系統被銀行的內部人員和專家所熟知。他們知道所有的細節、所有的困難、所有可能 出現的問題、所有的業務規則。這些就是我們永遠的起始點:領域。
模型：
模型是軟體設計中最基本的部分。我們需要它，是因為能夠用它來處理複雜問題。我們對 領域的所有的思考過程被彙總到這個模型中。這樣甚好，但它必須要脫離開我們的頭腦，如果 它始終停留在我們的頭腦中，其實並不會有多大的作用，不是嗎?我們需要就這個模型跟領域 專家進行交流，跟相關的設計人員進行交流，跟開發人員進行交流。模型是軟體的根本，但我 們需要找到一些方法來表達它，與其他人交流這個模型。在這個過程中我們並不是孤立的，所 以我們需要彼此共享知識和資訊，而且我們需要把它做得更好、更精確、更完整，沒有二義性。 要做到這點有多種方式。一種方式是圖形化的:圖形、用例、繪畫、等。另一種方式是文 字描述，我們會寫下我們對領域的願景。還有一種方式是使用語言，我們能夠也應該建立一種 語言，來對與領域相關的特定問題進行交流。在以後的章節中我們會詳細講解它們，但要點就 是，我們需要用模型來交流。
**設計：
軟體設計有不同的方法，其中之一是瀑布設計方法。這種方法包含了一些階段。業務專家 提出一堆需求同業務分析人員進行交流，分析人員基於那些需求來建立乙個模型，然後將建模 的結果傳遞給開發人員，開發人員根據他們收到的東西開始編碼。在這個方法中，知識只有單 一的流向。雖然這種方法作為軟體設計的乙個傳統方法，這麼多年來已經取得了某種程度上的 成功應用，但它還是有它的缺點和侷限。主要問題是業務專家得不到分析人員的反饋資訊，分 析人員也得不到開發人員的反饋資訊。
另一種方法是敏捷方法學，例如極限程式設計(xp)。這些方法學是不同於瀑布方法的一些活 動，其產生的原因是很難預先確定所有的需求，特別是在需求經常變化的情況。要想預先建立 乙個覆蓋領域所有方面的完整模型確實非常困難。需要做出大量的思考，而且在初期常常無法 看到涉及到的所有的問題，也無法預見到設計中某些帶有負面影響或錯誤的部分。敏捷方法試 **決的另乙個問題被稱為「分析癱瘓」，團隊成員會因為害怕做出任何設計決定而止步不前。 儘管敏捷方法的倡導者承認設計決定的重要性，但他們反對做出預先設計。相反，他們借助於 實現層面的靈活性，通過由業務涉眾持續參與的迭代開發和很多重構，開發團隊更多地學習到 了客戶的領域知識，從而能夠產出滿足客戶需要的軟體。
通用語言：
領域驅動設計的乙個核心的原則是使用一種基於模型的語言。因為模型是軟體滿足 領域的共同點，它很適合作為這種通用語言的構造基礎。
使用模型作為語言的主幹。要求團隊在進行所有的交流時都使用一致的語言，在代 碼中也是這樣。在共享知識和推敲模型時，團隊會使用演講、文字和圖形。需要確保團 隊使用的語言在所有的交流形式中看上去都是一致的。因為這個原因，這種語言被稱為 「通用語言」(ubiquitous language)。
模型轉換為**：
為了實現實現和模型之間的緊密**，通常需要支援建模範型(例如物件導向程式設計) 的軟體開發工具和語言。
物件導向程式設計來實現模型，因為它們基於同乙個范型(即，物件導向)。面向 物件程式設計提供了物件的類、類之間的關聯關係、物件例項、以及物件例項之間的訊息通 信。物件導向程式設計語言使得在帶有關聯關係的模型物件與它們的程式設計對等物之間建立直 接的對映成為了可能。
模型驅動設計的基本構成要素：
模式和模式間關係的總圖：
分層架構：
領域驅動設計的乙個通用的架構解決方案包含了 4 個概念層:
使用者介面/展現層
負責向使用者展現資訊以及解釋使用者命令應用層很薄的一層，用來協調應用的活動。它不包含業務邏輯。它也 不保留業務物件的狀態，但它保留有應用任務的進度狀態
領域層本層包含關於領域的資訊。這是業務軟體的核心所在。在這裡 保留業務物件的狀態。對業務物件和它們狀態的持久化被委託 給了基礎設施層
基礎設施層
本層作為其他層的支撐庫存在。它提供了層間的通訊，實現對 業務物件的持久化，包含對使用者介面層的支援庫等作用
實體：
值物件：有的時候我們需要包含乙個領域物件的某些屬性。我們對它是哪乙個物件並不感興 趣，而是只關心它所擁有的屬性。用來描述領域的特定方面、並且沒有識別符號的乙個對 象，叫做值物件。
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd？1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...