RubyConf Taiwan 2023 - 嘗試與能量
今年參加的最後一場研討會 RubyConf Taiwan 在昨天結束,比較意外的點大概是意外的玩得挺開心,倒是讓我有一點每次去日本參加 RubyKaigi 會在 After Party 跟很多人交流的感覺。
今年參加的最後一場研討會 RubyConf Taiwan 在昨天結束,比較意外的點大概是意外的玩得挺開心,倒是讓我有一點每次去日本參加 RubyKaigi 會在 After Party 跟很多人交流的感覺。
google/wire 是一個依賴注入(Dependency Injection)的工具,透過程式碼生成(Code Generate)來幫助我們解決 Golang 中一個物件對另一個物件有依賴關係時,需要事先產生的問題。
在開始這篇之前,也建議閱讀從 wire 學到依賴注入沒有講的事了解一些基本的概念。
這一系列算是一個新的嘗試,以往在撰寫技術文章時大多會將許多情報壓縮在一篇的內容中討論,然而這樣的情報量對許多人來說仍然是負擔很大的。
即使將其拆分到約四個月的內容量,我仍發現很難在不細說 Domain-Driven Design、Clean Architecture 等等觀念完善的解釋,但我還是選擇不特別去提出這些內容。
Entity(實體) 和 Aggregate(聚合) 是商業邏輯的基礎要素,我們將資料轉換成有意義的資訊,若要討論到該如何運用這些資料,那麼就屬於 Service(服務)和 Use Case(使用案例)的負責的部分。
倉庫跟實體是相當基本的概念,然而還不足以涵蓋更多的情境。我們還需要討論 Aggregate(聚合)的情況,以我們這次的例子來說,就是一種聚合的表現。有了 Aggregate 的概念後,就可以逐步看出一個系統的邊界。
在我們實作訂閱功能的過程中,提到了像是 Entity(實體)還有 Repository(倉庫)等關鍵字,現在我們要來回顧一些這些使用的物件有怎樣的特性,在 Rails 中我們應該如何使用,才能避免預期外的問題。
經過這段時間的實作,我們的規格已經逐漸確定下來而且更加清晰,現在我們終於到了決定儲存方式的階段,目前的功能採用關聯式資料庫(RDBMS)儲存算是相當適合的方式,因此我們可以直接利用 ActiveRecord 來實現。
假設我們繼續確認訂閱的需求,發現現有的功能無法記錄使用者在何時進行延展,因此希望加入「在 2023-03-14 延展」的資訊在畫面上,然而我們現在是使用整數儲存在 Subscription
的 #items
屬性中,除了無法明確表達意義外,也不容易再繼續擴充。
到目前為止,我們已經透過驗收測試保護了我們想實作的功能,然而有一些實作如果不儘快重構,很快就會變成難以維護的技術債,因此在提交部分程式碼後,我們需要盡快的對這些地方做處理。
大多數的訂閱功能都會希望有紀錄的機制,假設我們也收到了同樣的需求。那麼,我們現在除了訂閱之外,還需要加入「訂閱紀錄」的設計,讓我們的使用者可以知道訂閱了多少次,或者可以手動延展訂閱。