撰寫測試的方式有很多種，如何為軟體加入測試也是一門深奧的學問。我個人是比較推薦使用 A-TDD（Acceptance Test Driven Development，驗收測試驅動開發）跟 TDD（Test Driven Development，測試驅動開發）兩種方式來進行開發。

大多數使用過 Ruby 的工程師都知道 Ruby 有一個特別的語言特性叫做 Mixin（混合）可以透過定義一個 Module（模組）然後被其他類別引用，如果從 DCI（Data Context Interaction）的角度來看，其實是一種脈絡的表現。

測試幾乎是現代軟體開發的必備技能，然而我們對於測試的理解、撰寫、使用的熟練程度，會極大的影響我們的軟體是否穩定，也因此具備一個優質的測試技能對於軟體的品質與改善都會有非常大的影響。

最近在實作一個會員集點功能的時候意外發現很適合作為「領域事件（Domain Event）」的例子，在很多情況下其實不容易去描述這個概念，然而這個例子倒是很好的反應這個概念，以及 Rails 的特性所產生的變化。

對脈絡（Context）比較有清晰的概念是在今年研究 Domain-Driven Design 的時候，這幾天剛好因為工作需要修正 Golang 的靜態分析警告，想到這其實也跟脈絡有些關係，因此這篇文章會來跟大家分享幾種常見的「程式脈絡」

最近因為 OpenAI 的 ChatGPT 推出，很多人開始嘗試，也得到了不少令人驚豔的結果。甚至有一些人開始開玩笑說「以後就讓 AI 寫程式吧！」之類的。不過，如果對這項技術有一定程度的了解，這個夢想也許還挺遙遠。

教召一直是讀書的好時機，因此我利用五天的時間把 Clean Architecture 讀完。讓我覺得意外的是，以往我聽到在討論一些主題時會提到這本書的內容，其實大多跟這本書想傳達的資訊不太一致，除此之外我認為有很多值得討論的地方也沒有被大家討論。

之前在查資料時，在 Twitter 上看到 DHH 對 DCI (Data Context Interaction) 的看法同時上週的我對 Domain-Driven Design 的理解（2022 年）這篇文章也提到了 DDD 跟 DCI 不互斥，而且能夠改善某些設計上的問題。

因為把 Domain-Driven Design: The First 15 years 看完後腦中有了非常多想法，為了不要太快把這些東西忘記，只能盡快寫成文章記錄下來。

簡單來說，我認為 Domain-Driven Design 是一種「觀念」而不是理論或者實踐，他更接近於將「模型（Model）」的概念帶入到程式設計中，也因此在書中提到 Domain-Driven Design 是沒有嚴格規定，只有接近跟遠離核心的差異。

這幾年因為疫情的關係，還有參加研討會大多著重在交流上所以不太特別寫部落格來紀錄聽到的議程。然而，今年的 MOPCON 剛好是被邀稿，選了一個跟以往風格不太樣的的主題，同時也是自己選擇挑戰「創業」要用到的題目，一年的累積剛好在這場活動出現了質變。