如何為事件溯源專案規劃技術堆疊 -Keith Mifsud

banq發表於2019-09-25
事件

在與開發人員，工程師和軟體開發實驗室就新的Event Sourcing專案進行培訓或諮詢時，我遇到的最常見問題是我們如何以及從何處開始。
這個問題非常有意義。我記得在實踐中試圖繞過物件導向程式設計（不是我在學校學到的廢話），更不用說理解領域驅動設計了！
大約十年前，我為當時最大的客戶之一：工業製冷和空調系統的製造商，批發商和分銷商，建立了一個相對複雜的線上和離線銷售和物流系統。
在該專案的三個月中，我的團隊有三名軟體工程師：兩名後端Web開發人員和一名前端開發人員。我們取得了卓越的進步。我們正在使用DDD模型和Laravel作為應用程式框架來構建此係統。很好，我們富有成效。
我選擇PHP作為主要的後端程式語言。但是，我有信心，規劃因素適用於您要用於Event Sourcing專案的任何程式語言。在本文中，我將概述規劃基礎結構和兩者之間的應用粘合的注意事項。

事件儲存資料庫
事件儲存最關鍵的永續性儲存是事件儲存資料庫。如您所知，您可以使用幾種不同的資料庫引擎來執行事件儲存。在這篇文章中，我將不比較這些引擎中的任何一個，因為我們需要知道的是我們需要一個附加的最佳化資料庫。
鑑於事件源的不變性，我們當然不需要更新任何持久事件。我們也不需要執行任何複雜的讀取查詢。正如我將在以後的文章中提到的那樣，事件儲存實現將查詢由聚合的UUID（通用唯一識別符號）標識的持久事件。那是一個非常簡單的查詢。
我也不鼓勵在NoSQL資料庫上實現您的事件儲存。
無論如何，我都選擇在MySQL   資料庫上實現事件儲存  。我發現  PostgreSQL   對於Event Store的實現也非常有用，並且我已經使用了幾次。
這樣，我就對清單應用程式的基礎結構做出了第一個決定。我將使用MySQL來保留事件。但是，我將透過使用儲存庫模式將所有模型的程式碼與該決策分開。因此，如果將來改變主意，則只需要更改實現並以某種方式遷移資料即可。

讀取模型資料庫
儘管我以前使用MySQL來保持讀取模型的永續性，但是我為讀取模型實現NoSQL資料庫的次數越多，我越喜歡NoSQL給應用程式提供的靈活性。
我將  MongoDB   用作該系統的讀取模型的資料庫，除了我在日常工作中經常使用它外，沒有其他特殊原因，因此我對此非常滿意。

應用框架​​​​​​​
我需要一個應用程式框架嗎？可以說，我沒有。我需要一個可由使用者訪問的應用程式層，例如使用者介面。但是，我在應用程式層中還需要一些其他基本元件。這些順序不分先後：
-能夠解析我的依賴項的具體實現。
-可以輕鬆地將所有具體實現與新實現互換的功能。
-傳入請求和模型之間的反腐敗層。
-客戶端和使用者的某種形式的身份和身份驗證。
-能夠使用環境變數隔離可配置選項。
可能還有其他一些要求，例如引導整個過程
然，我們可以使用一堆解耦的元件，它們可以一起滿足所有要求。我以前做過，甚至成功過。為什麼不繼續使用Laravel 這樣的框架呢  ？

API訪問​​​​​​​
我還打算將GraphQL用作API的查詢語言。我發現  GraphQL   和無模式的讀取模型是完美的選擇。但是，這很可能導致使用更少的Laravel HTTP層，因為（例如）GraphQL型別系統可以充當應用程式層的反腐敗層，而不是Laravel的請求物件。使用此API還意味著我可能需要自己開發GraphQL實現，因為（當前和AFAIK）用於GrapghQL和Laravel的所有當前庫都使用Eloquent作為型別系統。我不會將Eloquent用於讀取模型，因為它克服了我非常喜歡的無模式優勢。

更多php程式碼細節點選標題參考原文，本文程式碼：Git儲存庫 ​​​​​​​
 

相關文章