關於 #架構 的內容

這一系列我們會使用 Hono 這一個近幾年才出現的框架，跟 Node 生態系常使用的 Express 框架不同，Hono 最初是以 Cloudflare Worker 環境運行設計，後來逐漸發展成適合 Serverless 環境的框架。

跟以往不同的地方在於，加入 AI 到產品與開發流程過後，許多以往的思考方式會有所改變。因此這一次我們的目標除了原本實現的功能外，還要考慮新型態的軟體開發方式。

寫完 Clean Architecture in Go 系列後，原本預定是要探討 Ruby 相關的主題，然而剛好遇上大量的 AI（人工智慧）應用出現，加上手邊正好使用 TypeScript 做了一些實驗，才有了這一系列的出現。

我們討論了不少 Clean Architecture 在 Golang 實踐的方式和技巧，然而我們是否真的有必要在 Golang 使用，以及使用之後我們能獲得怎樣「實質」的優點。我們經常會聽到 Clean Architecture 的優點，卻很少有實際的案例討論。

Clean Architecture 提到許多軟體開發的設計模式和原則，當我們將系統一定程度的套用這些設計後，就能得到很不錯的擴充能力。假設現在需要對資料庫的讀取功能加入快取機制，來應付逐漸變大的流量，能如何實作呢？

使用 sqlc 的前置準備已經完成，我們現在可以透過 sqlc 產生的程式碼直接跟資料庫互動，然而生成的實作和我們在 UseCase 期待的介面不同，因此需要實作 Repository 來將介面統一。

使用 BoltDB（或者 NoSQL）類型的資料庫跟我們原生的 InMemory 模式還是相當接近，那麼利用 Repository 抽象化的特性轉換成 RDBMS（關連式資料庫）是否可行呢？答案是肯定的，我們會使用 sqlc 來支援 SQLite 或者 PostgreSQL 和 MySQL。

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

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

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