關於 Domain-Driven Design 以及他的魅力
在我剛開始工作時，曾思考這個行業的價值與未來在哪里，直到有天我翻到了一篇文章，裡面有一句話打動了我： 在這個時代，寫程式從來沒有那麼簡單過，但要解決的問題也空前的困難。 軟體的核心是他為使用者解決領域相關問題的能力。隨著許多如金融、電商、社交等行業提供的服務越來越強大，軟體需求的複雜度也跟著起飛。身為一名工程師已經不能單純只做好自己的螺絲釘就能完成任務。 大多時候，程式設計的重點並不在於使用哪個框架技術或優化幾個百分比，而是在於 是否能忠實解決業務的需求 。 因此 Eric Evans 發明了領域驅動設計 (Domain-Driven Design ，之後簡稱 DDD) ，提倡開發人員也需要與領域專家合作以獲取足夠的業務知識 (business knowledge)，接著將領域知識與業務邏輯注入進程式碼模型之中，達成「程式即設計、設計即程式」的境界。 運用了這套模式，一來程式碼功能一目瞭然，二來可以有效保護我們的業務邏輯不被竄改，甚至可以適應未來業務邏輯的變化與成長。 DDD 最大的價值之一就是把將商業領域的知識映照到程式碼中，解放「程式歸程式，業務歸業務」的傳統思維 ，在過程中甚至可以打破商業團隊與工程團隊間的藩籬，甚至會讓人感覺到： 開發其實是一場學習的過程，程式碼只是過程的副產物。 DDD 是什麼 介紹 DDD 是什麼之前，我們先定義領域 (Domain) 是什麼。廣泛來說， domain (knowledge) 是指「一塊知識的範圍」。實務上，就是指「你工作上所需的一切知識集合」，包含「問題」以及「解決方案」。 由此可見， DDD 是一種基於 領域知識 來 解決複雜業務問題 的軟體開發方法論。 他有以下三個重點： 跟領域專家 (domain expert) 密切合作來定義出 domain 的範圍及相關解決的方案。 切分領域出數個子領域，並專注在核心子領域。 透過一系列設計模式，將領域知識注入進程式模型 (model) 中。 用 Ubiquitous Language 溝通 現代軟體的複雜特性，沒有一個人或是團隊可以單獨掌握所有的知識細節，甚至連領域專家的理解都可能有所缺漏。為了要盡可能獲取知識的全貌，我們會將溝通所得到的知識提煉出來達成共識後，建立 Ubiquitous Language (通用語言) ，減少溝通的成本。 ...