DDD理解

DDD體現的是對現實的充分尊重。
1.尊重業務現實，領域專家、領域語言等概念
2.尊重團隊現實
3.尊重變化

Application

• 對某一業務線的整體掌控，流程組裝，進度管理，存儲時機掌控。
• 依賴外部模塊的業務環節實現；
• 儘量滿足UI需求；
• 落地：uow提交；

Domain

• 業務線視作水平線的話，此處應在垂直方向上切分各業務線，重新整合抽象，處理具體的業務環節、業務步驟。
• 劃分範圍、確定職責，需要多維度多視角的考慮抽象；
• 粒度儘量小。
• 本質上是對業務邏輯處理過程的純化，能用的技術手段實質上是受限的；
• 不要考慮業務邏輯跨項目跨產品的通用性，這是以後的事；
• 緩存和倉儲需要註意，有必要的話分開；
• 落地：儘量少的執行 存儲，最好沒有；
  在記憶體中處理邏輯；
  儘量使用private set;
  儘量避免鎖與線程操作；
  註意時間、時刻及引用的問題；

存儲、查詢

• 存儲的重要性僅次於Domain。
• 存儲的隔離有兩種，一種僅隔離不同的資料庫，一種連ORM也隔離開；
• 大多數情況下不需要隔離ORM，技術選型確定後，使用時不必有過多顧慮；
• 如果使用EFCore這種ORM，DbSet和DbContext可以進入Domain；
• 查詢與存儲關聯非常緊密同時距離用戶很近（兩個地獄），技術手段可以放寬，存儲過程、Db函數，lua腳本之類都可以考慮；
• Domain可以對查詢進行一些適配，或優化（後期）；
• 快照時機，快照性能；
• 實時、非實時查詢；
• 複雜報表需要自行適配業務數據；

命令、事件、消息。。。

• 匯流排隊列比較容易被接受；
• 事件可以分階段落地；
• 就算是日誌也要養成記錄快照的習慣；

標識

• 避免自增Id；
• 分散式id，大部分時候可以使用CombineGuid（唯一、基本有序、隨機、提前生成）；
• 進行事件快照時可以使用同一id，不同事件類型進行處理。
• 通常會發生變化的對象需要一個標識。

實體與值對象

• 實體屬性會產生變化用於描述記錄業務生命期內的各種事件，實體本身及引用的實體都會變化，實體間的關係通常使用引用來表達；
• 值對象本身是偏概念的東西，用過函數語言的會比較容易理解，在c#中與之類似的有元組、匿名類和提案里的record；
• 這裡最重要的是思想的引入而非手段。
• 值對象本身表達的是部分屬性的快照副本，類似於實體擁有的所有屬性上的一段切片，是某個時刻下的一小段副本，所以不需要標識也只能是只讀的；
• 屬於使用者/調用者關註的東西，如果沒有人關註它，通常沒有必要單純為表達某個概念而增加，容易造成概念混亂；
• 實體的變化會使邏輯處理產生隱患，尤其是涉及到引用類型時，這時引入值對象的快照副本概念就會很自然，比如使用一些變數取出屬性值，或者一個匿名類用於方法內部，或者在方法的參數上僅提供值類型的參數，總之“邏輯演算法僅能處理當前時刻的對象狀態” 這一層概念必須明確表達。
• 實體的邏輯處理通常會導致實體自身屬性的變化，業務上對實體屬性的變化通常很敏感，有時不能僅提供一個結果給需求方，這時我們就需要增加一些屬性記錄下結果產生的原因。
• 值對象不在於我們定義的類型結構，而是要幫助技術人員建立起值的概念，快照副本及當前時刻是關鍵點，這種概念的建立非常有助於理解業務事件；
  ------------------------------------------------------------------上面是值對象值的部分，下麵是對象部分（結構，屬性包）；
• 有時候我們的邏輯中會有“我不關心是什麼類型的實體，我只關心是否符合某種結構（屬性包，形狀）”，也就是實體在不同視角下的形狀，關註點產生了變化。
• 一般在一些橫切式的模塊或者分析類的模塊中有應用。
• 字典、配置類使用實體，更新原狀態，插入新記錄。

後臺

• 系統後臺：監控，分散式管理。。。；

• 管理後臺不可直接引用Domain自行組裝業務流（使用介面）；
• 管理後臺的需求必須與業務線需求一同交給Domain處理；

• 手工操作功能沒有小事；

  安全許可權

  貫穿始終；

團隊

• 溝通、信任 “敬汝代碼而惕之”，