關於 #Domain-Driven Design 的內容

當我們要透過 Ruby on Rails 這個框架來開發這樣的系統時，該如何進行設計呢？大多數時候我們會以模型（Model）為基礎思考，這在 MVC（Model ViewController）框架上還算常見，因為核心邏輯大多會被實作在 Model 上。

在專案初期客戶有提到，第一階段要處理的客戶是最複雜的，只要能夠解決這個客戶的需求，未來就能夠讓客戶服務的其他客戶都能夠使用這套系統。

報表功能也是非常常見的情境，大多數時候我們都會直接使用 Rails 的資料庫內容，搭配 JOIN 類型的查詢進行處理，然而這並不總是個好辦法。

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

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

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

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

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

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

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