極客時間學習筆記為什麼微服務設計的時候需要ddd？
（1）軟體架構模式演進的三個階段：
第一階段是單機架構；
第二階段是集中式架構；
第三階段是分布式微服務架構；
（2）在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。
（3）微服務拆分困境產生的根本原因就是不知道業務或者微服務的邊界到底在什麼地方。
（4）ddd 核心思想是通過領域驅動設計方法定義領域模型，從而確定業務和應用邊界，保證業務模型與**模型的一致性。
（5）ddd 包括戰略設計和戰術設計兩部分：
戰略設計主要從業務視角出發，建立業務領域模型，劃分領域邊界，建立通用語言的限界上下文，限界上下文可以作為微服務設計的參考邊界。
戰術設計則從技術視角出發，側重於領域模型的技術實現，完成軟體開發和落地，包括：聚合根、實體、值物件、領域服務、應用服務和資源庫等**邏輯的設計和實現。
（6）在從業務模型向微服務落地的過程中，也就是從戰略設計向戰術設計的實施過程中，我們會將領域模型中的領域物件與**模型中的**物件建立對映關係，將業務架構和系統架構進行繫結。當我們去響應業務變化調整業務架構和領域模型時，系統架構也會同時發生調整，並同步建立新的對映關係。
（1）通用語言定義上下文含義，限界上下文則定義領域邊界，
（2）限界上下文的作用
1、主要是為了消除通用語言在不同領域中的歧義或者說是限制通用語言的使用範圍。
2、是劃分領域的重要依據
3、通用語言必須與限界上下文配合使用才有意義
（3）實體和值物件都是領域模型的成員，實體是業務唯一性的載體，是個富物件，包含業務邏輯和唯一標識。
（4）值物件是屬性的集合，沒有唯一標識，只是資料的容器，沒有業務邏輯。值物件是實體的一部分，為了簡化設計，將部分相關屬性抽離成值物件。
（5）如果值物件變動，原來的值物件可以直接丟棄。也可以理解為值物件是當時資料的快照，只是當時的狀態。
（6）值物件過多會導致業務的缺失，影響查詢效能。具體哪些屬性可以作為值物件存在要具體問題具體分析。
（1）貧血模型是指使用的領域物件中只有setter和getter方法，所有的業務邏輯都不包含在領域物件中而是放在業務邏輯層；
（2）充血模型將大多數業務邏輯放在領域實體中實現，實體本身包含了屬性和它的業務行為，它在領域模型中就是乙個具有業務行為和邏輯的基本業務單元；
（3）實體和值物件兩者都經過屬性聚類形成，實體有唯一性，值物件沒有；
（4）實體著重唯一性和延續性，不在意屬性的變化，屬性全變了，它還是原來那個它；
（5）值物件著重描述性，對屬性的變化很敏感，屬性變了，它就不是那個它了。
（1）在微服務內，不是少用領域事件，是少用事件匯流排。
（2）在ddd中是以聚合為單位進行資料管理的，如果一次操作會修改同乙個微服務內的多個聚合的資料。
（3）為了解耦不同聚合，你需要採用分布式事務或者用事件匯流排兩種方式。
（4）事件匯流排不太方便管理服務和資料的關係，可以用類似saga之類的分布式事務技術。總之需要確保不同聚合的業務規則和資料一致性，儘量減少系統建設複雜度。
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
領域驅動設計（DDD）
ddd是一種軟體設計方法，簡單來說，就是先建立一套業務領域的軟體模型，然後以此模型為核心進行軟體設計和開發。ddd主要有以下幾個優點 1 ddd會建立一套模型，即領域模型，這個模型是業務領域知識的濃縮，可以避免領域知識的流失。2 ddd和物件導向程式設計高度契合，領域模型將一比一直接反映到 中，由此...