iT邦幫忙

2021 iThome 鐵人賽

DAY 29
0
Software Development

在 Ruby on Rails 中導入 Domain-Driven Design 是不是搞錯了什麼?系列 第 29

[DAY29] 總回顧

導入 DDD 後專案真的有變比較好嗎?

  • 從測試的角度

    之前的篇章中有提到,舊有測試都是以 controller 和頁面文字進行測試,因此可以視為測試覆蓋率為 0 %,以此基準來比較的話,導入 DDD 後測試覆蓋率提升約 60 %。

    這邊的測試覆蓋率包含原生 rails 產生的 model、worker 等等及 domains 資料夾,不包含 controller 及 view。

    這代表單元測試變得更好寫,工程師更願意花時間去寫測試,而完整的單元測試能保護程式碼不出現非預期的行為更動,也能降低下次開發的時間與成本。

  • 從需求的角度

    DDD 流程中需要花很多時間與業務人員和領域專家討論,在溝通過程中會產生共通語言,共通語言能使所有利害關係人(stakeholders)站在同一陣線,不會造成我說的 A 跟你說的 A 不一樣的情況。這有效降低了開發出的功能沒有達到預期效果而做白工的情形發生,讓整個團隊從功能開發邁向需求開發。

  • 從 coding style 上來看

    有了 Boxenn 套件的幫助,整個專案的寫法便有了強制規範(相較文件來說),因此在開發時更能專注在需求開發,除此之外還能加速 code review 的時間。

  • 從知識傳承上來看

    對教育新人來說,不用了解所有過往的知識便能進行開發,業務知識已經被封裝在各自的 domain 中,如此一來能降低上手難度。

因此我覺得不論實踐程度如何,導入 DDD 確實對專案有不小的幫助。


上一篇
[DAY28] 戰略設計的彆扭事件
下一篇
[DAY30] DDD學習資源與完賽感言
系列文
在 Ruby on Rails 中導入 Domain-Driven Design 是不是搞錯了什麼?30

尚未有邦友留言

立即登入留言