模式設計篇，主要針對ddd的幾個重要概念進行了定義
主要分為entity/value object/service/module
引言：房東出租房壞了，起訴作者，其實是另外乙個同名同姓的人。隱喻：如何區分乙個物件
entity 需要有乙個標識定義，在生命週期內是連續的，而且不隨自身熟悉的變化而變化。說白了，需要乙個唯一標識。
entity 建模的基本原則是，確保連續性，保持實體的簡練，不要過多關注的屬性和行為上。
唯一標識的生成，例如jvm程序中的記憶體位址、分布式環境的唯一id、資料庫的自增id等。
引言：2個小孩畫畫，他只關心用什麼顏色、粗細的筆來畫，畫好後，他不用關係某個圖上的細節是什麼筆畫的。如果需要關係，這會非常複雜。
值物件：不可變物件，常量
需要考慮2個場景，複製和共享：（如：同乙個jvm中，共享合適，分布式場景，複製合適）
最好使用共享的場景：
1：節省資料庫空間是乙個效能關鍵點的時候
2：通訊開銷很低的時候
3：共享的物件被嚴格定義為不可變的時候
有時候，一些從概念上不知道該歸位哪一類事物的時候，經常會引用到service上
特點：動詞
bad case:
1：沒有為一些行為找到合適的物件，service的實現慢慢變成過程型**
2：一些service常常以物件（類）的形式存在，做一些沒有領域意義的事情，常常以-manager結尾
3：替換entity或者value object的某些職責
good case:
1：與領域模型的操作，不是entity 或者值物件的某一部分（不會越權）
2：介面根據領域語義定義
3：無狀態的
ps:應用層和基礎設施層，是可以有部分無領域意義的service。
module直觀好處有2個，乙個是在module中不會被細節淹沒、另外是可以直觀檢視module之間的依賴關係
通用設計原則：高內聚，低耦合。劃分上可以是**的分類、領域概念的分類。
命名應該以領域語義命名，反應領域的抽象知識
敏捷module,建議將單一概念物件的所有**打包在一起，原因有2點，
乙個是**散落在不同包裡面，無法清晰表達模型
乙個是人類的大腦還原能力有限，比較難關聯多個不同的mudule
《領域驅動設計 軟體核心複雜性應對之道》讀書筆記
1.eric evans強調要聚焦於軟體的核心領域，以它來驅動開發。軟體能夠在市場上賣出去。是因為它封裝了別的軟體所滅有的一些核心領域知識，這就是核心競爭力，是利潤所在的地方，也是最值得下功夫的地方，再難也不能逃避。2.有很多因素會是軟體開發複雜化，但最根本的原因是問題領域本身錯綜複雜。如果你要為一...
領域驅動設計之關聯設計
在找到實體與值物件後，我們就需要進行物件之間的關聯設計。1.關聯盡量少，不要形成複雜的關係網。複雜的關係網不利於劃分邊界，理解與維護物件，同時對效能也有不利影響，通常關係只找出在整個業務生命週期都需要存在的關係。比如乙個訂單項需要關聯到產品，但是仔細分析，乙個訂單項並不需要再整個業務生命週期都需要存...
領域驅動設計之 領域建模
普通開發者在開發乙個專案時，可能考慮到的都是如何實現業務邏輯，同時提高程式效能，好一點的開發者會同時考慮到 的復用性和擴充套件性，沒錯，上面提到的幾點都是乙個優秀的技術開發需要必備的素質，但是如果想要真正的做出好的專案，是需要深入了解專案所屬領域的專業知識，從而設計出易於維護，能夠滿足組織後續需求，...