
在 Place Order 實作 Token 機制 - Clean Architecture in Go
我們已經對於 Tokenization 機制的設計有大致的方向,那麼就可以開始來對 Place Order 的流程進行調整,將原本直接把客戶名稱儲存到 Order 改為先向 Token 機制要求產生一個代號,再作為原本的替代儲存進去。
Pager 2
我們已經對於 Tokenization 機制的設計有大致的方向,那麼就可以開始來對 Place Order 的流程進行調整,將原本直接把客戶名稱儲存到 Order 改為先向 Token 機制要求產生一個代號,再作為原本的替代儲存進去。
處理完在 Place Order 時將顧客名字轉換成代號(Token)進行儲存的處理後,我們也需要讓讀取出來的資料能將資訊轉換回原本的樣子,假設系統已經運行一段時間,我們還需要區分是否是尚未進行代號處理的版本,還是已經被處理過。
現階段我們已經將 Tokenization(代號化)的機制整合到原本訂單的使用者資訊中,然而在 Token
的紀錄中仍會存在明碼的資料,因此我們還需要加入加密機制來處理,要如何處理也是一個值得思考的問題。
RESTful API 的版本已經實作完畢,我們接下來會實作 gRPC 的版本,我們會透過這次的擴充,來了解為什麼 Controller 和 UseCase 會被切分開來。