關於 #心得 的內容

週末在評估 Tsuzuri 的前端框架該從 Stimulus 換到哪一套時，為了維持整體的輕量，評估過程中我打開了 Svelte 的教學文件，沒想到全程禁止複製貼上，倒是久違的手寫了一遍程式。

花一小時左右手寫後，我對於 Svelte 用很精簡的語法實作許多功能感到讚嘆，也開始思考讓 AI 實作時，還能找到這樣的驚喜嗎？

最近看到 n8n（自動化工作流程平台）的更新中加入了 LINE Messaging 的社群節點，花了一點時間研究才發現好心人竟然是自己。

因為已經有 n8n Line Messaging 社群節點教學以及 n8n Line API 串接教學：從零開始，打造你的專屬 AI 通知機器人兩篇文章介紹使用方式，這篇文章就來聊一下作者角度的看法。

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

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

經過一系列的實作，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 的概念後，就可以逐步看出一個系統的邊界。