軟體的核心是為使用者解決領域相關的問題的能力，其他特性都要服務於這個基本目的。
領域驅動設計告訴我們如何做好業務層，
並以領域驅動設計思想來選擇合適的框架，通過關注領域模型而不是技術來建立更好的軟體。
領域模型是通過逐步演化學習得來的，這當中體現了對相關領域知識的提煉歸納，是無法複製抄襲的，是整套軟體最具價值的部分。軟體設計的目的是研究如何使用計算機來解決實際（領域）問題，而不是去研究資料應該如何儲存更合理。資料模型主要用於描述領域模型物件的持久化方式，應該是先有領域模型才有資料模型，領域模型通過某種對映而產生相應的資料模型。什麼是模型？模型是簡化、是對現實世界的解釋，把與解決問題相關的方面抽象出來忽略無關的細節，它是用於解決資訊超載問題的工具。模型是一種知識形式，對知識進行有目的地簡化和有目的地結構化，建模不是對事物的模擬，而更像是在製作電影--出於某種目的而概括地反映現實。
領域驅動設計中領域模型=資料結構+操作方法(僅僅只有set、get屬性值的方法稱作貧血模型，加入了自身行為方法後稱作充血模型)，這樣才有了乙個富有生命力的完整的物件，資料則是領域模型的血液。在ddd倡導的充血模型的開發模式下，物件不僅僅只是乙個記錄事實結果的工具，而是乙個個活生生的能夠擁有自己個體行為以及能夠和其他物件互動的互動行為物件。此時，物件不僅可以記錄事實結果，而且表示事實發生的原因，即物件之間的相互互動協作，即這個事實結果是通過怎樣的事實產生的，領域內發出的事件一定是告訴別人我發生了什麼而不是請幫我做什麼。因此，基於ddd思想的物件不僅可以表示事實的結果，還能表示事實本身，物件互動指軟體領域模型中各個具有一定客觀性的物件之間的互動。
那麼相比傳統程式設計建模方式，領域驅動建模有什麼不同呢？
傳統的程式設計方式下首先思考的是資料，將資料從物件的行為當中分離出來，然後根據資料去建模建立成資料庫表等。
在領域驅動設計當中，首先關鍵考慮的是統一語言，並把統一語言用在**當中思考我們的模型能夠做什麼？然後逐步地暴露出其行為，再根據行為聯絡到資料。有了行為才有資料而不是通過資料去倒推行為。在此基礎上自然就產生出了關注分離，有了cqrs架構(命令與查詢職責分離)。在寫操作中我們考慮由哪些功能函式會改變系統哪些狀態，而讀操作中我們考慮在什麼地方為使用者展現什麼樣的檢視。所以強調考慮業務過程而不是資料。
在電腦科學當中，最難的兩件事情是命名和快取失效，在ddd的實踐當中，這兩件事情都將會遇到。
命名體現了領域模型的提煉過程，即聚合的邊界劃分：找到內聚性強的結構然後以該結構為邊界對系統進行劃分，當聚合體的名稱確定後聚合內部的實體與值物件的名稱自然也能確定了。命名問題指的是邏輯一致性問題，只有發現事物內在的邏輯一致性時才能給該事物起名。在ddd當中乙個聚合邊界內實現嚴格的一致性，聚合體之間實現最終一致性的更新。
快取失效則涉及實體狀態的變化，現代計算機工業採取有態和無態的劃分方式，這意味需要分析找出聚合當中的可變狀態與不可變狀態分開進行處理。快取冗餘失效談的是複製一致性的問題，在分布式環境當中如何取得可用性、分割槽容錯性和一致性的平衡需要考慮。
當命名好領域模型進入計算機**實施時，領域模型物件是生存在計算機的in-memory cache當中。領域模型物件的狀態是經常會被事件改變的，自然不可避免會遭遇狀態在
快取當中失效即更新問題，更新之後的快取失效又將導致資料的一致性等問題。當乙個複雜系統解決了命名和快取失效問題才意味著系統走向成熟穩定，將具有良好的可擴充套件性和可維護性。
DDD 領域驅動設計實踐 業務建模小招數
本文結合團隊在eco 社群服務系統 業務建模過程中的實踐經驗，總結得到一些ddd業務建模的小招數，不一定是完美的，但是對我們團隊來說很有效用，希望能幫到其他人。後面會陸續將專案中業務建模的一些經典例子放上來，分享給大家。eco系統是線上舊系統，它的建模過程有別於新系統的業務建模。由於揹著歷史包袱，e...
領域驅動設計之 領域建模
普通開發者在開發乙個專案時，可能考慮到的都是如何實現業務邏輯，同時提高程式效能，好一點的開發者會同時考慮到 的復用性和擴充套件性，沒錯，上面提到的幾點都是乙個優秀的技術開發需要必備的素質，但是如果想要真正的做出好的專案，是需要深入了解專案所屬領域的專業知識，從而設計出易於維護，能夠滿足組織後續需求，...
讀《領域驅動設計模式 原理與實踐》
美國，scott millett,nick tune 示例用的是 c 我喜歡本書的原理部分就是前部分。不喜歡的點是 建立和維護軟體的難處。bbom 是一大片隨意構造 雜亂無章 凌亂 任意拼貼 毫無頭緒的 叢林。大泥球，big ball of mud 領域複雜性和技術複雜性混合在了一起。的結果。缺乏應...