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太熟導致覺得敏捷無用、壓專案時程太方便導致沒有給團隊自主決定的機會、成功的大公司導致無法冒險也沒有容忍失敗的空間。
所以武俠小說裡面的橋段：「欲練神功，揮劍自宮」都是真的。
***
友藏內心獨白：該不會下一頁是不用自宮，也能成功吧！
