最近實際參與了工研院開源事件後被視為延伸的開源授權爭議。起因在初步處理後，有人詢問是否會有後續處理，我認同有後續處理，所以提出了調整用詞的建議，然而後續並未如我預期以更友善的方式繼續進行。

之所以會提出建議做出調整，是希望整個開源社群是朝向更正面、友善的風氣前進，而非無法容錯的方向。

當 Clean Architecture 的實踐完善後，我們在各種功能的抽換就能獲得許多彈性，接下來我們會以 BoltDB 來示範將原本儲存在記憶體的資訊，轉換為保存在硬碟的持久性版本。

在前面的案例中，我們並沒有考量到「輸入檢查」這件事情，因此在 gRPC 的案例中，我們發現即使沒有填寫 Name 也可以順利建立訂單，這並不符合我們的期待。

在上一階段我們完成了可以運行的 gRPC Server 接下來就可以將原本 RESTful API 上的實作移植到 gRPC 上，讓我們可以使用 gRPC 來操作這些功能。

RESTful API 的版本已經實作完畢，我們接下來會實作 gRPC 的版本，我們會透過這次的擴充，來了解為什麼 Controller 和 UseCase 會被切分開來。

AI（人工智慧）領域的發展非常快速，在二月之前我還不覺得以 AI 來寫程式是有效的，因為我需要複製程式碼到編輯器中，然而 My LLM codegen workflow atm 這篇文章改變了我的看法，因為有一些工具已經足夠成熟能直接編輯檔案。

有非常多額外內容，我會把下半年連載的展示專案跟閒聊另外放在 YouTube 影片 裡面討論。

現階段我們已經將 Tokenization（代號化）的機制整合到原本訂單的使用者資訊中，然而在 Token 的紀錄中仍會存在明碼的資料，因此我們還需要加入加密機制來處理，要如何處理也是一個值得思考的問題。

處理完在 Place Order 時將顧客名字轉換成代號（Token）進行儲存的處理後，我們也需要讓讀取出來的資料能將資訊轉換回原本的樣子，假設系統已經運行一段時間，我們還需要區分是否是尚未進行代號處理的版本，還是已經被處理過。

我們已經對於 Tokenization 機制的設計有大致的方向，那麼就可以開始來對 Place Order 的流程進行調整，將原本直接把客戶名稱儲存到 Order 改為先向 Token 機制要求產生一個代號，再作為原本的替代儲存進去。

訂單的建立和查詢已經完成，然而下單者的名字仍然被明碼儲存在我們系統之中，我們希望針對個資做更好的保護，因此決定導入代號化（Tokenization）的機制，將原本儲存的名字已代號（Token）儲存，並且將真實的資料另外加密。