NorthOne如何結合無伺服器與DDD實現數字銀行服務API？

工作流
NorthOne是一家使用者體驗公司，希望確保為小型企業提供儘可能最好的銀行體驗。NorthOne不想在運維上花費大量時間，並且一直嘗試這樣做，而且可靠性非常重要。
銀行業是一種工作流程：申請流程就是您輸入所有個人資訊，向您的銀行傳送請求，然後現在需要完成整個流程發生。各種檢查並確保人們不在任何欺詐名單或洗錢名單上，甚至只是從我們的合規部門獲得第二次稽核。
工作流程非常適合使用亞馬遜的step函式、暫停函式並能夠稍後返回響應，這樣您就可以為合規團隊和其他團隊構建其他內部應用程式。
  

Saga模式與無伺服器 
在事件世界中，當你談論像分散式事務時，那裡發生了很多事情，現在一個常見的模式是Saga模式。你可能不想做2PC兩階段提交和所有其他的事情，但是當我們研究Saga時，需要選擇編排或編舞。編舞會變得非常混亂，因為有很多簡單的行為。假設我是一個服務，我需要知道當事件發生時我需要做些什麼，我需要知道我轉儲哪些補償事件，以及所有其他的東西。
使用 step 函式就是進行編排的無伺服器方式，我們有一個流程，需要將大量帳戶或大量使用者資料移動到不同的系統，因此使用了編排中的協調器，讓其密切關注正在發生的一切，可能會暫停遷移，當開發人員完成他們的工作時，你按下一個按鈕，一切又重新開始啟動了。
最酷的事情之一就是重試能力：當人工操作失敗時，或者當這些工作流步驟之一發生失敗時，您可以確切地看到哪個步驟，您可以看到日誌。
Stripe 在他們平臺的某些部分做了很多類似NorthOne做的事情，你輸入個人資訊，你得到一個token，你在任何地方使用該token。NorthOne進行標記化，並限制透過調器中的步驟流動的細節數量。我們標識流程中的事件並儲存它們，並且我們將在步驟之間讀取回事件儲存，以執行我們需要執行的操作。這可能失去了一些除錯能力，您無法準確看到流程的資訊，但我們需要保證使用者資料的安全。
 

DDD事件風暴與事件溯源
事件風暴在領域驅動設計社群很流行，我們整個業務用便籤貼在牆上，最好讓每個業務利益相關者都聚集在一起，但幸運的是，我們的產品團隊有兩個人作為代表。我們在房間裡有產品方面人員來解決這個問題。
把我們的整個業務放在牆上，這需要幾天時間，然後在它周圍畫圈並反覆迭代一段時間。然後開始研究該技術的外觀。我們的領域邊界是什麼，我們需要製作什麼原型？在那裡的幾個星期裡，我們只是在做原型。
我們如何用餘額、最少的交易和一些新的模式開設一個賬戶。我們真的接受了一些領域驅動的設計思維，以及事件驅動的思維。
現在我們的整個系統通常最終會變得一致，如果您現在將所有架構劃分到域中，並解耦所有內容。我們建立了一些早期原型，我們建立了我們自己的事件儲存版本，也就是說，我只想說一個圍繞 DynamoDB 的自以為是的方案，我們在其中跟蹤修訂、有效負載、時間戳，以及您希望能夠做到的所有事情做事件溯源。
對於我們的許多用例來說，事件溯源似乎是狀態的正確方法。銀行業，如果您只考慮銀行分類帳，它就是事件或會計分類帳。
我們的事件儲存模式基本上變成了一個 DynamoDB，其中包含圍繞模式的意見，以及一個帶有簡單分派功能的共享程式碼包。一個真正著眼於強制執行樂觀併發的排程函式，然後我們還內建了一些 reducer 函式。
一旦我們建立了這些域邊界，我們就需要弄清楚我們如何在域之間和域內進行通訊。我們著眼於真正區分里程碑事件和領域事件。我想其他術語中的里程碑事件可能被稱為整合事件，但這種想法認為這些是關鍵的業務里程碑。一個賬戶被開啟，一個申請被批准或拒絕，每個域可能需要知道的事情。
我們需要考慮如何傳達所有這些資訊？我們如何溝通？我們登陸 EventBridge 加入我們的里程碑事件。我們有一輛與我們所有人交談的事件Bus。我們的每個服務現在訂閱該 EventBridge，並維護自己的事件儲存，這需要 DynamoDB 的支援。
我們做了很多重播，這是 EventBridge 最酷的事情之一。簡直太容易了。您只需設定一個存檔，它就會記錄所有透過的內容，然後您只需按下控制檯中的一個按鈕，它就會重播所有內容。
我們的每項服務都有自己的資料儲存。它通常是一個事件流或一個投影資料庫，舊平臺是使用 Postgres，而且我們確實有關係資料。很有意思。現在開始我真的很害怕，我們要怎麼維持關係這些事情？現在都使用DynamoDB。
詳細點選標題