對功能描述之後，我們需要將詳細的步驟寫下來，讓 Cucumber 知道該怎麼做來檢查這個功能是否符合預期，因此我們可以使用 Given、When、Then 來進行描述。

Cucumber 的測試撰寫基本上是非常容易的，因為我們不是去配合程式來實現測試，而是直接去撰寫測試後，讓程式去配合測試。

在實際了解 Cucumber 的應用方式之前，我一直認為使用 Cucumber 撰寫測試是一件非常麻煩的事情，因為我們會需要實作許多 Step Definition（步驟定義）來讓文件中的某個行為可以被使用。

然而，當我了解到 Cucumber 的價值之後，就變成我優先選用的工具。

大學的時候曾對朋友說過「極限不是用來超越的嗎？」這句話，即使畢業後快要十年，仍然符合現況。在 2023 即將結束，開始「這一年」似乎很適合用這句話作為標題。

今年參加的最後一場研討會 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 中我們應該如何使用，才能避免預期外的問題。