蒼時弦也Token 內容加密 - Clean Architecture in Go
現階段我們已經將 Tokenization（代號化）的機制整合到原本訂單的使用者資訊中，然而在 Token 的紀錄中仍會存在明碼的資料，因此我們還需要加入加密機制來處理，要如何處理也是一個值得思考的問題。
蒼時弦也關於 #架構 的內容
蒼時弦也蒼時弦也在 Lookup Order 實作 Token 機制 - Clean Architecture in Go
處理完在 Place Order 時將顧客名字轉換成代號（Token）進行儲存的處理後，我們也需要讓讀取出來的資料能將資訊轉換回原本的樣子，假設系統已經運行一段時間，我們還需要區分是否是尚未進行代號處理的版本，還是已經被處理過。
蒼時弦也在 Place Order 實作 Token 機制 - Clean Architecture in Go
我們已經對於 Tokenization 機制的設計有大致的方向，那麼就可以開始來對 Place Order 的流程進行調整，將原本直接把客戶名稱儲存到 Order 改為先向 Token 機制要求產生一個代號，再作為原本的替代儲存進去。
蒼時弦也Tokenization 機制設計 - Clean Architecture in Go
訂單的建立和查詢已經完成，然而下單者的名字仍然被明碼儲存在我們系統之中，我們希望針對個資做更好的保護，因此決定導入代號化（Tokenization）的機制，將原本儲存的名字已代號（Token）儲存，並且將真實的資料另外加密。
蒼時弦也Lookup Order 功能 - Clean Architecture in Go
基於 Place Order 的實作，我們的專案已經有一個不錯的雛形可以在相當容易擴充的狀況下繼續進行。然而，如果只能建立訂單仍不足以驗證功能完善，因此我們接下來要加入 Lookup Order 來確認是否順利的將資料儲存到記憶體中。
蒼時弦也Place Order 實作 Repository 部分 - Clean Architecture in Go
處理完整個流程後，我們可以來做最後的「狀態保存」處理，也就是 Repository（倉庫） 的實作。在這個階段，我們會先使用一個 InMemory 的版本，將狀態暫時性保存在記憶體中，等到我們後續有更完善的規劃後，再回來處理。
蒼時弦也Place Order 實作 Entity 部分 - Clean Architecture in Go
Controller 和 UseCase 都有對應的實作後，我們還需要定義在這個系統中負責管理狀態的 Entity（實體）才算是有一個基礎的系統雛形。在這個例子中，我們會需要 Order 和 OrderItem 這兩種實體。
蒼時弦也Place Order 實作 Controller 部分 - Clean Architecture in Go
我們已經透過 oapi-codegen 產生了 Controller 的介面定義，然而還沒有任何實作。在 Clean Architecture 中 Controller 要扮演 Adapter（轉接器）的角色，因此我們需要透過 Controller 把使用者的輸入轉換成 UseCase 可以使用的格式。
蒼時弦也操作介面設計 - Clean Architecture in Go
假設要從零開始開發，相對好的方式是以黑箱的角度思考。也就是我們以「使用者看到的樣子」開始建構系統，並且在過程中逐步的「提煉」將 UseCase、Entity 從系統中提取出來。
這種做法在使用 BDD（Behavior-Driven Development）或者 TDD（Test-Driven Development）也能幫助我們設計出一些初期的測試案例。
蒼時弦也案例說明 - Clean Architecture in Go
這一系列會延續以往的做法，以實際的案例來說明。這一次我們會選擇以「訂單服務」作為例子，然而並不是單純的訂單服務，是一個會針對個資加密處理的服務。