關於 #Clean Architecture 的內容

報表功能也是非常常見的情境，大多數時候我們都會直接使用 Rails 的資料庫內容，搭配 JOIN 類型的查詢進行處理，然而這並不總是個好辦法。

在整個系統的開發過程中，因為客戶的服務是世界性的，因此還需要考慮到時區問題。然而只是單純的時區換算並不會造成問題過於複雜，而是在時區的呈現上並不像我們平常理解的那樣。

現代大部分的軟體都會考慮到使用者體驗（User Experience）因此都會盡量設計成簡單易懂的操作，然而仍有一些例外的狀況，像是有高度專業需求的系統，或者一些傳統產業長久以來的習慣，當時客戶就屬於這一類型。

當時收到新客戶的需求時，表示是一套很老舊的系統無法維護，急需開發一套新系統來維持業務的運作。客戶自己的工程師已經忙不過來，因此找到我當時任職的公司協助開發這套新系統，並且表示他們已經分析完畢，只需要依照 ERD（Entity-Relationship Diagram）實作即可。

約 2010 年左右，我開始接觸到許多程式語言的社群、研討會，因此大量吸收許多軟體開發的知識。當時，在業界中一個很常被提到的職稱「架構師」對當時還是學生的自己似乎有點遙遠。而我直到十多年後，才意識到「架構」的意義。

答案是肯定的，遊戲也是軟體的一種，善用軟體架構相關的思考對於設計遊戲仍然非常有幫助。今年的 Global Game Jam 因為隊友都比較熟悉 Unity，因此我也挑戰在 Unity 實踐去年沒有完善的部分。

google/wire 是一個依賴注入（Dependency Injection）的工具，透過程式碼生成（Code Generate）來幫助我們解決 Golang 中一個物件對另一個物件有依賴關係時，需要事先產生的問題。

在開始這篇之前，也建議閱讀從 wire 學到依賴注入沒有講的事了解一些基本的概念。

最近在工作中對專案套用 google/wire 來處理依賴注入（DI，Dependency Injection）時，發現有非常多小細節需要注意。大多數語言其實都會碰到這類問題，然而 wire 的設計沒有採用大多數框架會提供的控制反轉（IoC，Inverse of Control）機制來處理，反而讓很多過去沒有考慮的狀況浮現出來。

在遊戲開發中寫測試一直以來都是被認為相當困難的一件事情，雖然有很多人嘗試，但我們仍沒有找到一個很好的方法解決。

同時，寫測試對許多人來說是一種拖慢開發速度的工作，這次我在每年都會參加 Global Game Jam 中挑戰用 48 小時的時間開發，運用這段時間學到的 Domain-Driven Design（領域驅動設計）、Clean Architecture（清楚架構）、敏捷開發、ATDD（驗收測試驅動開發）等技巧來做實驗。

• 遊戲：https://ggj2023.aotoki.cloud/（可能要等一下）
• 原始碼：https://github.com/elct9620/GlobalGameJam2023

教召一直是讀書的好時機，因此我利用五天的時間把 Clean Architecture 讀完。讓我覺得意外的是，以往我聽到在討論一些主題時會提到這本書的內容，其實大多跟這本書想傳達的資訊不太一致，除此之外我認為有很多值得討論的地方也沒有被大家討論。