主要是在開發過程中，個人對於領域驅動設計的實踐感悟和總結；也是對新進開發人員的培訓資料；希望對關注ddd的童鞋有所幫助。
領域驅動不是純粹的技術問題，領域建模（建立資料表只是一部分）是領域專家(客戶／產品團隊)和開發人員溝通努力、抽象的的結果。
領域建模的目的是，經過有效的溝通、詳細分析、 良好設計可以更好的適應未來的變化。
領域驅動設計的核心是建立正確的領域模型。
後端開發人員、產品人員
領域驅動設計是什麼？
領域驅動設計的核心是建立正確的領域模型，正確的反應業務，並適應變化。
為什麼建立乙個領域模型是重要的
(1). 領域模型是具有邊界的領域抽象，反映了領域業務需求的本質，邊界指只領域內所關注的部分；
(2). 領域模型只反映業務，和任何技術實現無關, 包括實體概念（如商品）和過程概念（資金轉賬）；
(3).領域模型確保業務邏輯內聚在乙個模型中，幫助可理解和重用；
(4). 領域模型幫助開發人員平滑轉換為軟體構造；
(5).領域模型貫穿軟體分析設計開發整個過程，領域專家、設計、開發人員始終保持溝通，共享資訊，確保軟體真正滿足需求；
(6).建立正確的領域模型並不簡單，需要領域專家、設計、開發人員積極溝通共同努力，然後才能使大家對領域(業務需求)的認識不斷深入，從而不斷細化和完善領域模型；
(7).領域模型是整個軟體的核心，是最有價值和最具競爭力的部分；設計足夠精良且符合業務需求的領域模型能夠更快速的響應需求變化；
領域建模時思考問題的角度
傳送命令給應用層要求其執行某個使用者命令；
定義系統要完成的所有任務，對使用者介面層提**用功能。對內呼叫領域層（領域物件或領域服務）完成業務邏輯，應用層不包含業務邏輯。
負責表達業務概念，業務狀態資訊以及業務規則，領域模型處於這一層，是業務軟體的核心。
限界上下文是個高內聚的領域模型（例訂單模組），是未來系統做水平拆分的關鍵，可以說就是將乙個限界上下文模型拆分公升級為乙個子系統。
開發人員可以簡單理解，限界上下文可以轉換成**，放在乙個高內聚的dll專案；
aggregateroot 聚合根
聚合，它通過定義物件之間清晰的所屬關係和邊界來實現領域模型的內聚，並避免了錯綜複雜的難以維護的物件關係網的形成。聚合定義了一組具有內聚關係的相關物件的集合，我們把聚合看作是乙個修改資料的單元。
聚合的特點：
(1). 每個聚合有乙個根和乙個邊界，邊界定義了乙個聚合內部有哪些實體或值物件，根是聚合內的某個實體；
(2). 聚合內部的物件之間可以相互引用，但是聚合外部如果要訪問聚合內部的物件時，必須通過聚合根開始導航，絕對不能繞過聚合根直接訪問聚合內的物件，也就是說聚合根是外部可以保持 對它的引用的唯一元素；
(3). 聚合內除根以外的其他實體的唯一標識都是本地標識，也就是只要在聚合內部保持唯一即可，因為它們總是從屬於這個聚合的；
(4). 聚合根負責與外部其他物件打交道並維護自己內部的業務規則；
(5). 基於聚合的以上概念，我們可以推論出從資料庫查詢時的單元也是以聚合為乙個單元，也就是說我們不能直接查詢聚合內部的某個非根的物件；
(6). 聚合內部的物件可以保持對其他聚合根的引用；
刪除乙個聚合根時必須同時刪除該聚合內的所有相關物件，因為他們都同屬於乙個聚合，是乙個完整的概念；
如何識別聚合及聚合根？
我覺得我們可以先從業務的角度深入思考，然後慢慢分析出有哪些物件是：
有獨立存在的意義，即它是不依賴於其他物件的存在它才有意義的；
可以被獨立訪問的，還是必須通過某個其他物件導航得到的；
如何識別聚合根？
如果乙個聚合只有乙個實體，那麼這個實體就是聚合根；如果有多個實體，那麼我們可以思考聚合內哪個物件有獨立存在的意義並且可以和外部直接進行互動。
entity 實體
不能獨立存在的業務物件，必須掛在聚合根上。
valueobject 值物件
定義：在領域中，不需要唯一鍵標識的物件，包括：
常見的值物件：
字串常量；
列舉；無主鍵約束的引用物件；
如果有兩個customer的位址資訊是一樣的，我們就會認為這兩個customer的位址是同乙個。也就是說只要位址資訊一樣，我們就認為是同乙個位址address。
領域中的一些概念不太適合建模為物件，即歸類到實體物件或值物件，因為它們本質上就是一些操作，一些動作，而不是事物。這些操作或動作往往會涉及到多個領域物件。
領域服務乙個很重要的功能就是可以避免領域邏輯洩露到應用層。
容易降低耦合，方便做到高擴充套件性；
領域聚合根之間很難做到強一致性，大多數都是最終一致性；
本層為其他層提供通用的技術能力；提供了層間的通訊；為領域層實現持久化機制；總之，基礎設施層可以通過架構和框架來支援其他層的技術需求；
開發人員／團隊需要和產品團隊／客戶保持充分的溝通。
實現領域驅動設計之感悟（一）
接觸領域驅動設計的概念，已有4年了。從看書了解的純理論，到實際專案應用中遇到建模問題的思考，逐漸提公升了建模能力。正好碰到2020年五一放假，想趁這個機會，寫一下我的學習感悟。公司內的業務沉澱達到一定量，現有老系統維護困難，這個時候，有必要引入領域驅動設計，在這裡簡稱ddd。產品經理的業務設計和最終...
領域驅動設計建模思考與實踐
軟體的核心是為使用者解決領域相關的問題的能力，其他特性都要服務於這個基本目的。領域驅動設計告訴我們如何做好業務層，並以領域驅動設計思想來選擇合適的框架，通過關注領域模型而不是技術來建立更好的軟體。領域模型是通過逐步演化學習得來的，這當中體現了對相關領域知識的提煉歸納，是無法複製抄襲的，是整套軟體最具...
讀《領域驅動設計模式 原理與實踐》
美國，scott millett,nick tune 示例用的是 c 我喜歡本書的原理部分就是前部分。不喜歡的點是 建立和維護軟體的難處。bbom 是一大片隨意構造 雜亂無章 凌亂 任意拼貼 毫無頭緒的 叢林。大泥球，big ball of mud 領域複雜性和技術複雜性混合在了一起。的結果。缺乏應...