蒼時弦也在 Place Order 實作 Token 機制 - Clean Architecture in Go
我們已經對於 Tokenization 機制的設計有大致的方向，那麼就可以開始來對 Place Order 的流程進行調整，將原本直接把客戶名稱儲存到 Order 改為先向 Token 機制要求產生一個代號，再作為原本的替代儲存進去。
蒼時弦也Clean Architecture in Go 系列
這系列有提供早鳥閱讀選項。
蒼時弦也蒼時弦也在 Lookup Order 實作 Token 機制 - Clean Architecture in Go
處理完在 Place Order 時將顧客名字轉換成代號（Token）進行儲存的處理後，我們也需要讓讀取出來的資料能將資訊轉換回原本的樣子，假設系統已經運行一段時間，我們還需要區分是否是尚未進行代號處理的版本，還是已經被處理過。
蒼時弦也Token 內容加密 - Clean Architecture in Go
現階段我們已經將 Tokenization（代號化）的機制整合到原本訂單的使用者資訊中，然而在 Token 的紀錄中仍會存在明碼的資料，因此我們還需要加入加密機制來處理，要如何處理也是一個值得思考的問題。
蒼時弦也gRPC Server 準備 - Clean Architecture in Go
RESTful API 的版本已經實作完畢，我們接下來會實作 gRPC 的版本，我們會透過這次的擴充，來了解為什麼 Controller 和 UseCase 會被切分開來。
蒼時弦也gRPC Server 實作 - Clean Architecture in Go
在上一階段我們完成了可以運行的 gRPC Server 接下來就可以將原本 RESTful API 上的實作移植到 gRPC 上，讓我們可以使用 gRPC 來操作這些功能。
蒼時弦也輸入檢查 - Clean Architecture in Go
在前面的案例中，我們並沒有考量到「輸入檢查」這件事情，因此在 gRPC 的案例中，我們發現即使沒有填寫 Name 也可以順利建立訂單，這並不符合我們的期待。
蒼時弦也資料庫抽換 - BoltDB - Clean Architecture in Go
當 Clean Architecture 的實踐完善後，我們在各種功能的抽換就能獲得許多彈性，接下來我們會以 BoltDB 來示範將原本儲存在記憶體的資訊，轉換為保存在硬碟的持久性版本。
蒼時弦也資料庫抽換 - SQLite（一） - Clean Architecture in Go
使用 BoltDB（或者 NoSQL）類型的資料庫跟我們原生的 InMemory 模式還是相當接近，那麼利用 Repository 抽象化的特性轉換成 RDBMS（關連式資料庫）是否可行呢？答案是肯定的，我們會使用 sqlc 來支援 SQLite 或者 PostgreSQL 和 MySQL。
蒼時弦也資料庫抽換 - SQLite（二） - Clean Architecture in Go
使用 sqlc 的前置準備已經完成，我們現在可以透過 sqlc 產生的程式碼直接跟資料庫互動，然而生成的實作和我們在 UseCase 期待的介面不同，因此需要實作 Repository 來將介面統一。
蒼時弦也實作 LRU Cache - Clean Architecture in Go
Clean Architecture 提到許多軟體開發的設計模式和原則，當我們將系統一定程度的套用這些設計後，就能得到很不錯的擴充能力。假設現在需要對資料庫的讀取功能加入快取機制，來應付逐漸變大的流量，能如何實作呢？