事件溯源導論

簡單是可靠的先決條件。 ——Edsger Dijkstra

推動DDD發展的動力是填補軟體架構師和領域專家在業務領域上的見解差異。與關係型建模相比，DDD是一項突破，因為它促進領域建模代替資料建模。關係型建模著眼於資料實體和它們的關係。而領域建模則著眼於領域中可觀察的行為。
事件溯源（Event Sourcing，ES）並非只是使用事件對業務邏輯進行建模。在ES場景裡，你的資料來源只包含持久化事件。
ES並非全能獨立的架構，而是一個能讓領域模型和CQRS等架構進一步發揮所長的特性。當把ES新增到系統時，你只是改變了資料來源的結構和實現。

1. 事件的突破
   
   1. 下一件大事
      總的來說，認為事件是軟體開發的下一件大事。繫結上下文以及領域事件和繼承事件共同為架構師指明瞭一條道路，使它們更有效地理解和實現需求。
      把可觀察的業務事件看做持久化資料為開發打開了新的視角。
   2. 現實世界不僅有模型，還有事件
      模型是現實的抽象，是架構師根據會面領域專家、利益相關者和終端使用者得到的結果建立的。
      最終，模型只是模型，而非我們在現實事件直接觀察到的東西。
   3. 拋棄“最近已知的正常狀態”
      當我們用觀察到的事件構建模型時，模型就是我們想要持久化的東西。一個模型通常是一組物件。
      ES的關注點主要在你觀察道德事件序列上。事件就是你想儲存到持久化儲存的東西。
      
      1. 最近已知的正常狀態：軟體正常執行時，某個物件的最近已知的正常狀態。
         一般而言，在實體的歷史裡也可能有事件改編實體的結構。“最近已知的正常狀態”方案是好的，但在業務領域裡展開時並非有效表示專案的生命週期的理想方案。
      2. 跟蹤剛才發生的事情
         從事件溯源的角度來看，事件是系統資料的主要來源。當一個事件觸發時，與之關聯的資料將被儲存。這樣，系統就能跟蹤正在發生的事情及其帶來的資訊。
   4. 事件對軟體架構的深刻影響
      
      1. 你不會錯過任何事情
         事件的主要好處是分析報告提到的任何領域事件都能在幾乎任何時候新增到系統並儲存到儲存。
         事件並沒有固定的格式或結構。事件只是一組屬性，將以某種方式持久化，但不一定持久化到關係型資料庫。
      2. 幾乎無限業務場景可擴充套件性
         事件會想你詳述某個特定領域裡的業務。
         處理事件持久化需要新的架構元素，如事件儲存，事件就是記錄在這裡的。
      3. 支援假設場景
         通過儲存和處理事件，可以再任何需要的時候構建內容的當前狀態。
         使用假設場景的可能性是使用ES的主要業務原因之一。
      4. 沒有強制要求的技術
         事件溯源並未顯式地繫結任何技術或產品。
         事件溯源需要某些軟體工具，主要是事件儲存。
         事件和事件溯源關乎架構；技術按照種類界定。
      5. 缺點：抵制改變
         如果你找到一個或多個領域專家需要你產生的事件序列，那麼事件許願就是一個進一步探索的方案。
2. 事件溯源架構
   決定把事件用作你的分層系統的主要資料來源時你需要做什麼。有兩個基本方面要考慮：持久化事件以及為查詢奠定基礎。
   
   1. 持久化事件
      事件應被持久化成審計日誌，並記錄以發生的事情。
      事件儲存時普通資料庫，但它不是用來持久化資料模型的。它持久化的是一組事件物件。
      事件儲存有三個主要特徵:
      ①它儲存的事件物件包含了重建這個時間引用的物件狀態所需的任何資訊。
      ②它必須可以返回與給定鍵關聯的資料流。
      ③它只能新增儲存，不支援更新和刪除。
      事件物件必須通過某種方式引用業務物件。
      
      1. 事件和業務邏輯的整體流程
         事件溯源基本上是關於以時間序列的方式捕獲應用程式狀態的所有改變。但是，事件是源自資訊。每個事件都是事件儲存裡的一條記錄，但每個事件都記錄了已發生的某件事。
      2. 事件儲存的選擇
         事件儲存最終還是一個數據庫。
   2. 回放事件
      事件溯源的主要作用是持久化訊息，它使你可以跟蹤應用程式狀態的所有改變。
      
      1. 構建業務實體的狀態
      2. 回放事件意味著什麼
      3. 資料快照
3. 總結
   事件促進基於任務的方案的分析和實現。
   構建一個保羅永珍的模型有時候很難，而命令和查詢之間的分離展示了更加高效地構建系統的方式。
   使用事件溯源時，每次重播事件都必須建立聚合狀態。

持久層

知識只是對事實的擁有，智慧則是對它們的活用。 ——Thomas Jefferson

從應用程式的角度來看，資料來源不再是物理資料庫，而是構建在業務領域之上的邏輯模型

1. 持久層概覽
   在某種程度上，現在的軟體都需要訪問資料，然後將資料儲存或者以某種方式展示給客戶。持久層這個名字通常用來指代瞭解資料訪問那些繁雜細節的程式碼：字串連線、查詢語言、索引和JSON資料結構等。

   1. 持久層的職責
      持久層通常會建立成類庫、被領域層（特別是領域服務）和應用程式層引用。持久層可以引用任何用於訪問資料的技術。
      
      1. 永久儲存資料 ：持久層提供一組類，它們知道如何永久儲存資料。永久資料是應用程式需要處理的資料，可以再將來任何時間繼續使用。
      2. 處理事務：持久層應該瞭解應用程式的事務需求，但是，持久層親自處理的應該只有與資料訪問有關的工作單元的事務。這意味著持久層應該負責在單個工作單元的某個聚合邊界內更新多個表。總之，持久層的事務職責不會超出資料聚合上下文裡的普通資料訪問的邊界。
      3. 讀取永久資料：持久層負責從任何永久儲存讀取資料。出於效能的考慮，更好的辦法是把讀取的工作放在單獨的伺服器列表上，並充分利用快取資料。持久層也是資料來源內容快取策略集中實現的理想地方。

   2. 倉儲模式的設計
      倉儲是一個類，裡面的每個方法都表示一個針對資料來源的操作——無論是什麼操作。這就是說，倉儲類的實際結構在不同的場景和應用程式裡可能會有較大差別。

      1. 倉儲模式：倉儲式一個協調領域模型和資料對映層的元件，使用類似集合的介面訪問領域物件。倉儲在分層架構裡所處的位置：
         
         使用倉儲的好處：

         • 實現關注點分離
         • 減少重複資料訪問程式碼的可能
         • 把資料訪問程式碼用作可注入元件，增加應用程式層和領域層裡的可測試程式碼。

         此外，一組良好隔離的倉儲類能為一些應用程式的部署打下堅實的基礎，以便一些資料訪問層可以應對不同的資料庫。

      2. 工作單元模式：Uow被定義構成一個業務事務的一組操作。一個支援這個模式的元件，比如倉儲，可以協調在單個物理事務裡的寫入更改，其中包括解決併發問題。總而言之，支援工作單元一位置呼叫方可以通過把倉儲暴露的操作組合起來安排邏輯事務。
      3. 倉儲模式與CQRS：若選擇CQRS，通常只在命令棧裡建倉儲，每個聚合對應一個倉儲類。倉儲類只有寫入方法和一個根據ID返回聚合的Get方法。在CQRS場景裡，只讀棧通常不需要倉儲類。
      4. 倉儲模式與領域模型：在領域模型場景裡，每個聚合都有一個倉儲。這個倉儲類會處理查詢和命令。
      5. 命令倉儲的介面：無論使用領域模型還是CQRS，都需要一個倉儲為聚合執行寫入操作。倉儲基於泛型介面，這個介面通常定義在領域層。介面的實現則通常放在基礎設施層的一個單獨的程式集裡。

2. 為何考慮非關係型儲存
   NoSQL，不僅僅是SQL。

   1. 哪些地方正在使用NoSQL：
      
      • 海量資料以及數百萬潛在使用者。
      • 每秒上千次查詢。
      • 非結構化/半結構化資料以不同形式出現，但仍需統一處理（多型資料）。
      • 使用雲端計算和虛擬化硬體滿足極端伸縮性需要
      • 資料庫是一個天然的事件源
   2. NoSQL型別：
      
      • 文件/物件儲存
      • 圖儲存
      • 鍵值儲存
      • 表格儲存

   3. 優缺點

      1. 關係型資料庫
         優點：

         • 支援標準資料訪問語言（SQL）
         • 表格模型易於理解，設計和規範流程定義明確。

         缺點：

         • 對通過SQL讀寫複雜型別僅提供有限支援
         • 需要資料庫結構的知識才能建立即席查詢。
         • 對大量記錄進行索引（數百萬行級別）會變得很慢。
      2. NoSQL
         優點：
         
         • 簡單的擴充套件
         • 快速讀寫
         • 低廉的成本
           缺點：
         • 不提供對SQL的支援
         • 支援的特性不夠豐富
         • 現有產品不夠成熟
3. 總結
   
   • 無需讀寫資料的應用程式和繫結上下文是不存在的。
   • 讀寫不一定發生在相同的資料儲存。其次，資料儲存不一定是資料庫。
   • 瞭解系統的機制和資料的特徵，然後制定出最可行的架構。
   • 針對企業場景，應該使用不同的儲存技術來儲存不同型別的資料。
   • 沒有理由通過單個技術或產品來統一儲存。
   • 多元化持久化要求你學習不同的儲存技術和產品。

2017/12/26 9:36:19

彩蛋

1. 今天的程式設計是軟體工程師和老天之間的競賽，前者努力構建更大、更好、白痴也能用的程式，後者嘗試創造更大、更好的白痴。到目前為止，老天領先。
2. 程式設計師的麻煩是你要等到一切都晚了才能搞清楚程式設計師在做什麼。
3. 給人程式，毀人一天；教人程式設計，毀人一生。
4. 你曾遇到的最大災難是你的第一門程式語言。
5. 程式是寫給人讀的，寫給機器執行指示偶然。
6. 面向物件的致富途徑是什麼？當然是繼承。
7. 如有疑問，蠻力為之。
8. 如果蠻力無法解決你的問題，那是你沒用力。
9. 好的判斷源自經驗，而經驗源自壞的判斷。
10. 電腦就像比基尼，避免人們過多猜測。
11. 如果你只知道SQL，那麼所有資料看起來都是關係型的。
12. 如果答案就是太多記錄，你可以改寫這句查詢嗎？
13. 如果開發者可以再你設計的資料庫裡放入錯誤的資料，那麼最終會有某個開發者這樣做。