最近一鼓作氣買了兩本久負盛名的書《領域驅動設計 軟體核心複雜性應對之道 》和《實現領域驅動設計》。開卷有益，在學習的途中，做些筆記鞏固下，並記錄下感想。先來說下《實現領域驅動設計》，大致翻了翻，本書並不是《演算法導論》那種很高階難懂的型別，是屬於思考實踐總結型別的。我相信，一章一章看下去，會有很多收穫的。本篇文章是個開篇說明，並不深究具體細節，講述如何使用《實現領域驅動設計》。
ddd的通用語言(ubiquitous language)作用於某個限界上下文（bounded context），它對於領域建模是非常重要的。
限界上下文是一種概念上的邊界，領域模型方便工作於其中。同時，限界上下文為通用語言提供了一套環境，專案成員通過通用語言來表達軟體模型，如流程圖：
站術設計的乙個重要模式是聚合（aggregate）,聚合可以由單個實體（entity)組成，也可以由一組實體和值物件（value object）組成，此時我們必須在聚合的整個生命週期保證事務上的一致性。
聚合例項通過資源庫（repository）進行持久化，另外對聚合的查詢和獲取也通過資源庫完成。如圖，兩個聚合型別，它們擁有各自的事務一致性的邊界。
在領域模型中，有些業務操作並不能自然的放在實體或值物件上，此時我們可以使用無狀態的領域服務（domain service),領域服務執行特定與領域的操作，其中可能涉及多個領域物件
領域事件（domain event）表示領域模型中發生的重要事件。有多種方式可以對領域事件進行建模。在對聚合進行命令操作時，聚合本身將發布領域事件。
我們通常忽略了模組（module),但是正確的設計模組同樣重要，模組內包含的領域物件應該是內聚在一起的。
以上內容主要提到了通用語言，限界上下文，上下文對映圖，聚合，實體，資源庫，值物件，領域服務，領域事件，模組等概念。
書上總結內容完畢。
ddd不是無中生有，自動產生的。它**於業務專家或軟體開發師在溝通提煉業務的基礎上歸納概括而來。所以在看書的過程中，會產生這個例子我見過，我用了相同的方法實現，感同身受的感受。也許當時你只是把問題解決了，並沒有引起你多大的深思。但有些人，有些思想家遇到了很多的例子，成功或失敗的例子，他們思考總結，寫的多了，最後成了一本書。嘭的一聲巨響，乙個領域專家誕生了！
本篇完畢，謝謝**。
《實現領域驅動設計》筆記
1 不要用貧血物件 雖然do是貧血的，但目前的do實際是dataobject，domainservice是實際的domainobject 2 多跟領域專家溝通 3 計費核心域為計費執行 1 計費執行包括計費條件 計費過程 計費結果 2 建立計費上下文，如計費時間 4 應用服務應當是無狀態的 5 分層...
領域驅動設計學習筆記 1
關聯簡化，從而讓模型更清晰 指定乙個導航的方向 加入限定符減少關聯的多重性 清除不必要的關聯 模型分為實體，值物件，服務物件三種 實體應具有唯一標識 id 來進行區分 值物件則為只關心它們是什麼，而不關心它們誰是誰的物件，所以不需要分配標識。通常是臨時物件，經常作為實體的屬性和其他值。設計時需要對複...
領域驅動設計學習筆記 1
關聯簡化，從而讓模型更清晰 指定乙個導航的方向 加入限定符減少關聯的多重性 清除不必要的關聯 模型分為實體，值物件，服務物件三種 實體應具有唯一標識 id 來進行區分 值物件則為只關心它們是什麼，而不關心它們誰是誰的物件，所以不需要分配標識。通常是臨時物件，經常作為實體的屬性和其他值。設計時需要對複...