200/11/27–28 是台灣第一屆的領域驅動設計 (下以 DDD 簡稱) 年會，光是聽到 DDD 很多人會以為是工程師的名詞，但這真的誤會大了，讓我先用一句話來介紹 DDD：
領域驅動設計 Domain Driven Design ，是透過專注理解領域問題並以此建構相對應軟體的一套方法
整個方法包含兩大部分：理解領域問題、以及建構相對應軟體。『理解領域問題』有很多可以討論的：誰該理解？理解什麼？怎麼理解？為什麼要理解？『建構相對應軟體』聽起來就是工程師的主場，但工程師光是看書上所寫很難有實際的感受，也一定不知道如何下手。
DDD 涵蓋的範圍非常的廣，初探 DDD 的人如我難免有上述一堆問題，這也很切合此次年會『讓更多人知道何謂領域驅動設計 (DDD)』的主軸。先說結論：參與後的收穫非常切合此主軸，也希望能透過引入 DDD 的方法來解決一些產品遇到的問題。簡短地寫一些各議程的心得：
Be The Change，一年 6.6 萬公里，開啟南台灣公司的敏捷旅程
講師： Hermes Chang 張昀煒 / 台灣敏捷協會 總舵主
對於 Action Learning 這個詞是第一次聽到，不過發現自己所在的團隊還滿符合這個特質的，也提醒了自己應該要再來繼續加強團隊的狀態可視化／視覺化，還有好好的寫 PRD 了～
對於南北差異有些共感，一些台北人如我覺得理所當然的事情，到中南部有可能完全不是如此，光是數位化程度的差異就很明顯。不過，對於學習的熱枕其實沒有什麼分別，大家都對新奇有幫助的事情有高度的學習興趣。很佩服 Hermes 致力於消彌這樣的資訊落差，回頭看看 Yourator 剛結束的台南博覽會其實做的也不錯（自己誇）。
將管理的需求規格落地
講師： Kevin 黃冠融 / Octalysis Prime/Software Engineer
雖然頭銜掛工程師，但花了很多時間理解產品背後脈絡，並與相關 stakeholder 討論，也與我們分享這段經歷。許多希望做出好產品的人都有個特質，都像個少林掃地僧，只要問他產品相關的他都有辦法回答你，不會因為掛了個工程師頭銜就對產品的其他面向一竅不通。
這也是 DDD 希望促進的，領域內各角色的互相了解，透過更了解彼此的需求我們才有辦法建構出更貼合實際狀況的軟體。
然後，畫個重點『語意統一就是在同一個上下文限界內一個事物只有一個名稱，不要有同義詞』
從使用者研究的幕後花絮談起
講師： Nor 陳啟彰 / 領潮創意設計企業社 / 社長
Nor 的講座總是以最真實的案例呈現了真實世界與我們理解的世界的巨大落差，這次的案例是台南的小黃巴士。案例中許多『數據上看不到的事情』很值得我們去細細思考，我們到底該如何去好好的評估、理解、解釋一件事情？普遍情況下透過數據可以有個概略的樣貌，但如果你不確定數據變化背後的原因，或是數據其實沒有與我們理解的方向變動，那麼也許我們該去親身體會一下現場到底發生了什麼事情了。
DDD 所提到的 Domain Expert 領域專家，常常就是這些我們需要研究的對象，當我們對使用者了解的越深，就越有辦法做出合理符合需求的系統了。
領域驅動的平台架構設計
講師： 王威 / ThoughtWorks
講到我們要定義詞彙，而詞彙凝聚著眾人的共識，眾人再依據這共識做演進。然後我就一直在思考言靈的力量：當我們可以把一個事物用明確的單詞念出來時，就可以有效地與他人溝通。甚至當一個詞彙定義的好的話可以像個自我應證的預言一樣，當大家都一直在講這個詞彙時，就可以往這方向邁進。我只要講『DDD』大家就都知道在講什麼，儘管大家認知的一定不同，但至少大方向不會差太多，然後就可以往多理解領域問題並加以解決的方向前進。
另外就是形塑事件時，可以從不同利害關係人身上看到大家對於事件的不同解釋，實際發生的事件通常不會有太多爭議，爭議端會在大家認為誰該為事件負責。負責人也影響到系統的設計，以及我們的價值取捨。
領域驅動設計 模型設計流程
講師：Kacper Gunia / 講師，顧問以及 DDD 倫敦組織者
聽說講師在歐洲一堂課要價上千歐元阿～整個賺到？但如果有參加第二天 workshop 就會知道其實台灣的實力也很棒只是課程價格比較難拉得這麼高。
不過光是講師提供的 https://github.com/ddd-crew/ddd-starter-modelling-process 這個 github repo 就很有價值，拿來思考如何引入自家產品的好工具。
我提問了『這些流程看起會需要許多資源，那要如何在組織已經有既有任務的情況下實現系統導入 DDD 的目標呢？』而講師 Kacper Gunia 不假思索的回答：『先想想你為什麼想要導入，可以幫助你解決什麼，先從可以直接解決問題的那塊去導入』（應該是被太多人問一樣的問題了 XD）
DDD + Clean Architecture：從需求到實作
講師：Teddy Chen 陳建村 / 泰迪軟體創辦人，部落格「搞笑談軟工」版主
軟體界誰沒聽過 Teddy 大大啊～在場的工程師應該都跑來這裡聽了。講 DDD 概念與 Clean Architecture 的結合，解答了自己許多的疑惑。很有共感的地方在許多東西第一次看可能會覺得沒什麼，但那不代表這東西沒有用，有可能是自己不懂，或是對當時的自己沒有用。等到時機到了，具備了足夠的知識，才有辦法讀懂。但還是很佩服 Teddy 在覺得沒什麼用的情況下還是陸陸續續地看了很多相關的書。
其他很多技術面的概念還需要多花時間消化，就不寫在這獻醜了。附上一張我很喜歡的圖
小結
如同文章開頭說的這次年會很符合『讓更多人知道何謂領域驅動設計 (DDD)』的主軸』，只是參與者仍是以工程師偏多，希望未來可以有更多的利害關係人加入。雖然活動上有許多地方看起來不盡完美，但人總有第一次，且若能秉持 DDD 的精神相信只會越來越好～
If I had one hour to save the world, I would spend 55 minutes defining the problem and only 5 minutes finding the solution.
分享自己在回家路的上看到的這段愛因斯坦名言。以前會覺得對啊做事當然要搞清楚問題再做，但實際上很多時候我們不知道有什麼解法、很多問題都是要跳下去做才有辦法理解、搞清楚問題真正在哪，然後等搞清楚的時候又已經沒有時間解決問題了。所以儘管我認為 DDD 很棒，但平常訓練自己解決問題的專業度（比如說，找 91 提升寫扣速度），練習觀察、找出問題癥結才是更需要訓練的基本功。有足夠的內力不管使什麼功伕都會比較威猛，不是嗎？
最後工商一下，我們正在尋找一同修行的工程師夥伴：https://yourator.teamdoor.io/s/D04DE5
