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

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

經過一系列的實作，Cucumber 的特色讓我們很容易的在不同語言、環境中轉換，同時又能夠扮演文件的角色，更難得的是他可以在不同語言中使用，這讓我們在未來對應不同需求時能有更大的彈性。

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

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

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

我們現在處理好保存狀態的機制，目前還剩下 POST /api/checkout 的實作還沒加入到裡面，除此之外每次開啟前端時也無法看到最新的購物車狀態，我們要來將這些情境處理到可用的情形。

使用 ActiveModel 將資料轉換成模型物件後，我們可以繼續利用 ActiveRecord 來跟資料庫整合，達到持久化資料的效果。接下來我們會修改現有的實作，讓資料可以持久化的被保存起來。

ActiveRecord 是基於 ActiveModel 所以製作的，因此我們只需要少量的重構就可以實現持久化保存的效果。

我們已經初步的完成可以給前端使用的 API 實作，然而在這個狀態下後端並沒有實際保存資料的能力，也有一些不好的實作方式（如：@@items 的 Class Variable）因此接下來我們要整合 SQLite 來作為持久化儲存的機制。

我們目前已經將商品資料的基礎 API 實現，接下來讓購物車新增、移除商品的行為也從前端轉移到後端，這段我們會需要加入相對多的調整來實現。