[DDD] 快快樂樂學DDD

簡報

Q&A

Q. 使用領域模型來分析系統物件，跟一般透過使用案例分析名詞、動詞來分析系統物件的差異為何?

A：透過使用案例來分析名詞、動詞，通常會是在SD階段或是PG階段，才開始對系統物件作分析設計的工作。而採用領域模型的方式則是將分析設計的工作，提前在RA階段就開始分析。並且在需求訪談的過程中，可以透過與客戶討論領域模型，來確認收集到的知識，是否真正為客戶所在領域的知識。

另外，透過名詞、動詞的方式分析，很容易讓開發人員設計出：Service物件+DTO物件的系統物件，也就是所謂的貧血模型。而關於貧血模型的相關討論，可以參考Martin Fowler這位大師所寫的：AnemicDomainModel - Martin Fowler。

Q. 使用Domain-Driven Design來分析設計系統，物件的測試資料怎麼取得?該如何驗證系統的正確性?

A：DDD在RA、SA、SD、PG各個階段提供「設計方針」，讓開發人員在設計的時候，能夠有可遵循的SOP來去分析設計系統，但這些設計方針，並不改變開發人員原有開發驗證流程。像我一樣習慣土法煉鋼的開發人員，一樣可以透過手動測試的方式，來驗證系統的正確性；而高級一些的開發人員，可以透過各種Unit test、TDD、BDD等等方式來驗證系統的正確性。

目前我預想中的開發流程：是透過DDD來從系統內部，分析領域知識並且最終產生物件模型；另外也透過TDD來從系統外部，分析系統該提供的功能、並且提供自動化驗證。經由這樣內外合併的分析、設計、驗證，最終就能架構出系統真正該有的物件與功能。(不過，TDD持續學習中，一直都有門檻跨不過...)