l

2019年10月18日 星期五

學習DDD有感

Oct. 18 14:46~16:18


客戶的發問

昨天下午到客戶家介紹領域驅動設計(Domain-Driven Design;DDD),以及如何運用事件風暴(Event Storming)、Clean Architecture、TDD的工具落實DDD。

活動結束時有同仁問Teddy:「你演講中提到DDD的好處我們都可以理解,具體上有沒有什麼實際的經驗可以分享?」

***

第一次接觸

Teddy首先想起幾年前剛接觸DDD,讀到《Domain-Driven Design: Tackling Complexity in the Heart of Software》這本書的情景。由於多年來Teddy已經習慣物件導向分析與設計(Object-Oriented Analysis and Design;OOAD)方法,當時覺得DDD強調建立領域模型(domain model)這件事,和OOAD並沒有什麼不同。另外書中提到的ubiquitous language、bounded context等觀念,其實就是pattern發明人Christopher Alexander在《Notes on the Synthesis of Form 》與《The Timeless Way of Building》等書中所提到的設計方法。至於DDD的Tactical Design(戰術設計)所包含的entity、value object、aggregate、factory、service、layered architecture這些patterns,也不過就是物件導向設計中常見的作法。

結論就是,這本書稍微翻一下就沒再理它了XD。

***

第二次接觸

過了一陣子,可能是因為微服務(Microservice)流行的緣故,DDD也跟著流行起來,Teddy同溫層的「臉友」談論DDD的人漸漸多了起來。這也引起Teddy的好奇,想說光看《Domain-Driven Design: Tackling Complexity in the Heart of Software》可能不夠,又買了幾本DDD的書,花了不少時間用力讀了一下。此時對於DDD所提出的這堆patterns的內涵有比較完整的認識,但總覺得,要開發軟體我就用熟知的OOAD就可以了,找不到一個施力點來使用DDD。

***

第三次接觸

兩年前在指導教授的建議之下,Teddy停掉在北科大資工所兼任的「軟體生命週期管理」課程,改教「軟體架構」。當時剛好Robert C. Martin 的新書《Clean Architecture: A Craftsman's Guide to Software Structure and Design》 出版,Teddy就用這本書當教科書。兩年來為了學習與教學的目的,Teddy設計兩個不同的專案,用了好幾種方式來詮釋Clean Architecture的實作。後來發現搭配DDD的domain model、ubiquitous language、bounded context、event storming、entity、aggregate、repository、service、domain event等pattern,以及Clean Architecture,加上採用TDD/BDD/SBE的方式實作系統,可以很漂亮的串起這些軟體開發方法。

此時,Teddy才慢慢感受到DDD的威力,特別是ubiquitous language in code的實踐,對於軟體的開發與維護所帶來的好處。另外,aggregate與domain event的使用,讓系統模組自然支援現今主流的分散式架構,這是傳統OOAD方法需要特別而外去關注才做得到的地方。

***

第四次接觸

約一年前Teddy帶幾位研究生開發一個看板系統,當初一開始設定的目標是要採用Clean Architecture作為此系統的架構。隨著開發活動進行,慢慢發現使用到DDD patterns越來越多,像是原本Clean Architecture就很強調的domain model,以及DDD的ubiquitous language in code、aggregate、repository、service、domain event等。

多年來Teddy也帶過好多組學生開發軟體,每次都立下宏願,希望用畢生所學,讓學生可以開發出「高品質」軟體。坦白說,多年來這個宏願一直無法實現。一方面研究生時間不多,要修課、寫作業、過日子,而且每年都有學生畢業,真正有時間投入專案開發頂多就是一個寒暑假而已。

另一方面學生的軟體開發能力與經驗也不足,還在學習當中,不容易要求在短時間內就可以做出設計良好的系統。

但是,這次開發看板系統Teddy感受到一絲曙光。初期Teddy花了很多時間與學生code review,先確認他們的Clean Architecture沒有走偏(目前還是有點偏,但至少沒有歪的太厲害)。後來隨著一個個user story實作的機會,幫助學生認識如何落實domain model與ubiquitous language in code。Teddy覺得光是這兩點做到,再搭配Clean Architecture,整個軟體系統的可讀性提升好幾個檔次。

Teddy希望有朝一日能做到「即是是學生所開發的軟體,也能夠達到專業的水準」。

***

老外幫我們做實驗

Teddy後來告訴發問的同仁:「DDD外國外已經提出10幾年了,有很多老外已經幫我們做過實驗。落實DDD的難度相對而言是比較高的,但是一旦公司與團隊能夠掌握這項方法,以我切身的經驗,我相信可以讓軟體開發更接近『讓軟體變軟』這個目標。」

落實DDD除了技術上的門檻以外,還有一點非常重要,就是團隊中有沒有領域專家,以及這位(或這一票XD)領域專家是否願意與開發團隊緊密合作,採用迭代與增量的模式,共同建立軟體系統的domain model與ubiquitous language。

DDD的技術門檻,可以來上泰迪軟體的〈Clean Architecture這樣學就會了實作班〉補足。至於有沒有領域專家願意與團隊緊密合作,就只能靠緣分了XD。

***

放下偶包

整個學習DDD的過程讓Teddy有一個很深刻的感觸:「很多時候以往的成功經驗可能會阻礙自己學習新的事物。」OOAD太熟導致一開始忽視DDD、Waterfall太熟導致覺得敏捷無用、壓專案時程太方便導致沒有給團隊自主決定的機會、成功的大公司導致無法冒險也沒有容忍失敗的空間。

所以武俠小說裡面的橋段:「欲練神功,揮劍自宮」都是真的。

***

友藏內心獨白:該不會下一頁是不用自宮,也能成功吧!

3 則留言:

  1. 只是因為缺了有相關 Domain Know How 的 SA/SD 吧...
    1. 太針對程式本身是沒有意義的
    2. 「初期Teddy花了很多時間與學生code review」著眼點整個大錯誤,完全沒必要
    3. 執著於某些模式跟方式對實際應用並無太多幫助

    可惜了,本以為所謂專業師資有些真正的內容,
    拜託別訓練出只會理論不會實務的學生...
    PM/SA/SD/PG 的程度就是這樣被一步步拉低的

    回覆刪除
    回覆
    1. 1. 太針對程式本身是沒有意義的:這就是為什麼台灣軟體寫的那麼爛,連改都改不動,架構在好,code連看都看不懂也是沒有用。
      2. 拜託別訓練出只會理論不會實務的學生:只學理論沒有實務的觀念您是從哪裡看到的?
      3. 只是因為缺了有相關 Domain Know How 的 SA/SD 吧:DDD強調的方式是透拓IID的方式與domain expert慢慢擴充出domain model並且建立通用語言,而不是傳統waterfall的開發方式透過一人弄出requirement,透過一人設計system architecture
      4. PM/SA/SD/PG 的程度就是這樣被一步步拉低的:專業分工,彼此互相靠杯,傳統command control方式,台灣的軟體就是這樣一步一步被拉低的....

      刪除
    2. 3. 執著於某些模式跟方式對實際應用並無太多幫助:那是因為一堆台灣工程師只會憑著無聊的感覺卻撰寫程式,卻連書都不看,還反過來說這些沒用,也是好笑,是你不會,不是模式沒有幫助,呵呵

      刪除