關於 #Rails 開發實踐 的內容

這一系列算是一個新的嘗試，以往在撰寫技術文章時大多會將許多情報壓縮在一篇的內容中討論，然而這樣的情報量對許多人來說仍然是負擔很大的。

即使將其拆分到約四個月的內容量，我仍發現很難在不細說 Domain-Driven Design、Clean Architecture 等等觀念完善的解釋，但我還是選擇不特別去提出這些內容。

Entity（實體） 和 Aggregate（聚合） 是商業邏輯的基礎要素，我們將資料轉換成有意義的資訊，若要討論到該如何運用這些資料，那麼就屬於 Service（服務）和 Use Case（使用案例）的負責的部分。

倉庫跟實體是相當基本的概念，然而還不足以涵蓋更多的情境。我們還需要討論 Aggregate（聚合）的情況，以我們這次的例子來說，就是一種聚合的表現。有了 Aggregate 的概念後，就可以逐步看出一個系統的邊界。

在我們實作訂閱功能的過程中，提到了像是 Entity（實體）還有 Repository（倉庫）等關鍵字，現在我們要來回顧一些這些使用的物件有怎樣的特性，在 Rails 中我們應該如何使用，才能避免預期外的問題。

經過這段時間的實作，我們的規格已經逐漸確定下來而且更加清晰，現在我們終於到了決定儲存方式的階段，目前的功能採用關聯式資料庫（RDBMS）儲存算是相當適合的方式，因此我們可以直接利用 ActiveRecord 來實現。

假設我們繼續確認訂閱的需求，發現現有的功能無法記錄使用者在何時進行延展，因此希望加入「在 2023-03-14 延展」的資訊在畫面上，然而我們現在是使用整數儲存在 Subscription 的 #items 屬性中，除了無法明確表達意義外，也不容易再繼續擴充。

到目前為止，我們已經透過驗收測試保護了我們想實作的功能，然而有一些實作如果不儘快重構，很快就會變成難以維護的技術債，因此在提交部分程式碼後，我們需要盡快的對這些地方做處理。

大多數的訂閱功能都會希望有紀錄的機制，假設我們也收到了同樣的需求。那麼，我們現在除了訂閱之外，還需要加入「訂閱紀錄」的設計，讓我們的使用者可以知道訂閱了多少次，或者可以手動延展訂閱。

我們對在不明原因重複訂閱的情況加入了 DuplicatedSubscription 的例外，然而這種情況是無法在驗收測試的狀況下被重現出來，因為使用者無法在正常狀況做到這件事情，在這種狀況下單元測試就非常適合。

有一些情況，並不會在規格上被描述出來，我們該去測試嗎？舉例來說，目前的實作在建立訂閱的時候，並不會檢查「重複訂閱」的狀況，雖然在介面上使用者是無法進行這樣的操作，我們應該去測試這樣的情況嗎？