最近開始看 Donmain-Driven Design 的 plurasight 的影片 ，其裡面有一句話深深吸引我，而當我開始看 DDD 的教學影片時，發現需要知道的內容，是多麼的廣泛，這句話當之無愧。。

The more you know, the more you realize you know nothing

Socrates

為什麼需要 DDD?

DDD 開發專注在理解使用者的需求，專注在 Domain 上，理解之後才開始寫程式碼。 t DDD 有其準則跟模式，幫助我們解決困難複雜的問題。 能夠幫助我們寫出代表 Domain 乾淨且可測試的程式碼，

DDD 幫助我們專注在更小、獨立 Domain，讓我們在開發上更為準確。

需要一位 Domain Experts

在 DDD 開發上，是非常重視溝通，其需要一位懂專業領域的專家，幫助我們釐清問題，其 Domain Experts 可以是合作的客戶、可以是專案上的 PM 等等….

用一張大圖來表示 DDD

Slides 的這張投影片，這就 DDD 需要懂的概念，因為剛開始在學習，目前懂的東西還不多，為了呼應開頭的引言，就先放在這邊嚇嚇大家XD

DDD_Big_PictureDDD_Big_Picture

DDD 的優點

  • 延展性
  • 站在使用者的角度來看問題
  • 有一套流程處理複雜的問題
  • 幫助我們寫有組織且可測試的程式碼
  • 所有的商業邏輯集中在一個地方
  • 有很多 patterns 可以在專案中使用

雖然 DDD 提供很優點，像是好維護，並有一套的溝通方式幫助我們理解複雜的商業邏輯，但是這應該是用在有複雜商業邏輯的專案上。

While Domain-Driven Design provides many technical benefits, such as maintainability, it should be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.

Eric EvansDomain-Driven Design

DDD 的缺點

  • 花時間
    • 溝通並理解商業邏輯，理解什麼問題該被解決
    • 將商業邏從應用程式中獨立出來
  • 學習曲線
    • 不同的開發原則
    • 新的 patterns
    • 新的開發方式
  • 只用在擁有複雜商業邏輯的專案上
    • 不適合用無複雜商業邏輯的專案，只有在做 CRUD 的情境上
    • 技術複雜但是商業邏輯簡單的情境，也不適用
  • 公司也需要同意執行 DDD 才可以!!!!

小結

DDD 真的是一個很大的主題，在看影片上，常常同一個影片也要多看幾次，才稍微理解裡面講的內容。 也因為剛開始學習的關係，若提及的內容與讀者理解稍有不同，也歡迎留言告知。