關於 Domain-Driven Design 以及他的魅力

Highlights

• 開始前想先跟大家介紹一個有名的反模式: 貧血模型 (Anemic Model)，這個反模式泛指那些只有 getter 與 setter 的 model

  • Note: 我以為只有getter跟setter的model 是不錯的

• 沒有什麼方法是銀子彈，只是各取所需罷了。 DDD 的強項在於解決複雜的業務邏輯以及拆分他們

  • Note: 在商業邏輯複雜且不是一般人可以在市面上常見的

• 是否能忠實解決業務的需求

  • Note: 髒亂的 code 只要能符合業務就是好code

• 業務語言做封裝也解決了兩大程式難題之一：命名

  • Note: 的確好的naming很重要，用共同的業務邏輯做naming很大一部分處理了工程師要自己想出各總奇怪的，naming

• 建立 **Ubiquitous Language (通用語言)**，減少溝通的成本

• 充滿業務含義的命名方式

  • Note: 門面模式？