關於 #經驗 的內容

最近在規劃工作中的一個服務重構，目標是要讓團隊在擴充新的資料源時可以更加快速，以及允許其他團隊貢獻新的資料源。剛好在讀軟體架構原理｜工程方法時裡面介紹的 Microkernel 架構剛好就很適合用來處理這類問題。

最近在帶同事做 Temperature Reading 時拿了一個卡了一段時間的功能出來討論，過程中發現在我們學習軟體開發的經驗中，對於抽象化的訓練大多只停留在「定義一個 Animal 物件」這個層次的理解。

花了一點時間大致上讀了一遍維基百科 Abstraction 的條目，也驗證了我感受到的狀況。

這個問題我個人目前還沒有一個邏輯足夠完整的答案，然而最近思考後認為蠻適合拋出來討論。

會回過頭來思考這個問題，也是因為對 Clean Architecture 的使用足夠熟練，要開始準備來深入了解經常一起應用的 Domain-Driven Design，那就一定會遇到這個問題。

最近因為工作的關係稍微回顧了一下 Open Policy Agent 而發現了 AWS 推出的 Cedar Language 更適合在軟體應用上實現類似 AWS IAM 的 Policy（政策）機制，因為是以 Rust 為基底，為了讓 Ruby 可以使用，就決定嘗試使用 Rust 來撰寫 Extension。

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 來實現。