關於 #Rails 的內容

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

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

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

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

經過調整成 ViteRuby 的專案結構後，我們已經讓 Vite 所撰寫的前端恢復基本的功能。然而我們使用 Grape 所撰寫的後端行為還無法正常運作，因此接下來我們要用類似的方法將後端重新實現，並且通過所有的 Cucumber 測試。

我們在前面的練習中大部分的實作都是可以直接沿用，唯一需要重新處理的是 Cucumber 的步驟定義，他會受到使用的語言、框架需要重新撰寫，接下來我們會先將前端的實作搬移到 Rails 中讓專案能夠運作起來。

在前面的實作中我們將前端跟後端分別獨立進行開發，這是很常見的一種方式。然而在 Rails 7 的生態系裡面，透過 jsbundling-rails 可以很輕鬆的整合在一起，接下來我們會使用類似基礎的 ViteRuby 把前端的 Cucumber 測試搬移到 Rails 上重現一次性整合完畢的實作。

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

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

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

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