關於 #Domain-Driven Design 的內容

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

最近工作上以及私下跟朋友討論時，剛好都遇到了 Null（不存在）類型的處理，通常我不會特別去在意這件事情，然而近年讀了一些關於 Null 的文章後（如：The worst mistake of computer science）對於這件事情的看法有不少改觀。

端午節連假利用空檔轉換心情時，把去年重寫後沒有完成的玩具再次拿出來挑戰，剛好在處理一對多的關聯時發現 Domain-Driven Design（領域驅動設計） 中對於 Aggregate（聚合）要作為統一操作其關聯的 Entity（實體）的原因。

有段時間沒有寫 Domain-Driven Design（以下簡稱 DDD）的主題，最近剛好跟一些朋友討論以及做了不少實驗，覺得可以針對這些題目再一次討論在 Ruby on Rails 中導入會遇到的問題。

在遊戲開發中寫測試一直以來都是被認為相當困難的一件事情，雖然有很多人嘗試，但我們仍沒有找到一個很好的方法解決。

同時，寫測試對許多人來說是一種拖慢開發速度的工作，這次我在每年都會參加 Global Game Jam 中挑戰用 48 小時的時間開發，運用這段時間學到的 Domain-Driven Design（領域驅動設計）、Clean Architecture（清楚架構）、敏捷開發、ATDD（驗收測試驅動開發）等技巧來做實驗。

• 遊戲：https://ggj2023.aotoki.cloud/（可能要等一下）
• 原始碼：https://github.com/elct9620/GlobalGameJam2023

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

之前在查資料時，在 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 是沒有嚴格規定，只有接近跟遠離核心的差異。