Domain Driven Design Taiwan Community 1st Meetup @ 2019–01–26 活動紀實

緣起

Sign D by hands ~

自從2018年的秋天,國昭(Arthur)與我幾次討論關於DDD的問題之後,Arthur覺得應該要開個領域驅動設計的社群在台灣,不假思索的很快就在Facebook上開展了,那是個充滿正向話題的夜晚,我們腦袋裡只有想著怎麼樣讓這個主題在台灣可以有更多人認識他,更多人了解他 …

只有當你踏向前了,才會有機會探尋出可能的戰友 ~

在將近社群成立了半年左右的時間,社群的成員人數已經來到300多人..

伴隨著這樣的人數的增長,觀察了在社群的文章與討論內容發現到一個現象,就是可能還是有很多人其實不那麼知道究竟DDD(領域驅動設計)是個什麼樣的概念? 這也催促著我們想要趕緊開辦第一次的實體聚會交流,希望能認識社群裡的大家,找到一個互動的機會一起來聊聊彼此心中所認知的DDD究竟為何。

心念把定之後就開始了第一次meetup的活動發起,由於我們是個很新的社群,希望能讓更多人知道,於是也透過很多夥伴朋友,以及友好的其他社群夥伴的互相分享,在很快的時間內累積了令人咋舌的報名人數…

87人按下參加,147人有興趣 ~

1/26是一個非常貼近農曆年的年前週末了,我心裡頭想著究竟會是萬人響應無人到場的情況,還是真的就人滿為患? 各種的擔憂忐忑伴隨著時間越來越拉近,我心裡的壓力也就越來越大了,因為活動當天我們安排的議程與工作坊為:

  1. Why DDD Matters — Kim Kao
  2. Event Storming Workshop — Arthur, Kim

想到一次有這麼多人會到場,究竟怎麼跑Event Storming在短短的時間內可以留住精華作為一個引子,讓大家後續繼續琢磨成了一個很挑戰的考驗,而實際活動當天到場人數也超過了70人 ~

青春,彷彿就是緊握在手中的現在啊..

為了讓當天沒有到場的朋友,也能多少了解一下我們當日的活動歷程資料,可以參考以下簡報網址:

講題回顧 — Why DDD Matters

一開始準備這主題的時候,主要目標是希望能給大家一個基礎的概觀,聊聊DDD是什麼,以及近來已經變成Buzzwords的 Microservices(微服務),説說什麼是為服務,你為何需要它,以及你真的準備好迎接它的到來了嗎

DDD is a collaboration way to crunch real problem

其實軟體(軟件)它存在的目的是為了解決真實問題領域而創建出來的,我們經常會需要從痛點下手,要從痛點下手便需要真正能夠探索真正問題,從而去設計與實踐解決方案,並且隨著時間的推進,對於真實世界的問題理解的深度層次更深更廣,我們需要將已經做出的軟體成品不段的迭代優化以迎合真正的問題需要。

然而,聰明如你,經驗老道的你肯定會遇到困擾,在勾勒這些解決方案的過程中,我需要與很多的不同團隊(利益關係人)打交道,我需要不同的資源投入(金錢、調研、外包、增聘人力、協作第三方等等 ),而有了這些之後我還得考慮到真實系統搭建完成後上線的運維以及項目實施的管理等等,這些的現實面經常都以 不同的維度在不同的時間進行溝通著,沒有一個很簡單可以把人都拉著一起討論的機會

換一個角度思考,大家看過很多球賽比賽,尤其像是NBA, MLB等等,很多球隊當中都有各種不同國籍的人,面對比賽的變化基本上如果不能講

  1. 同樣的語言
  2. 同樣的戰略思考
  3. 同樣的戰術實踐

那麼這樣的球隊肯定一盤散沙,無法將團隊戰力攻防一體的表現出來。Eric Evans 在2003年第一次談到領域驅動設計時,其實給我最大的收穫就是上面這張圖,用統一的語言來做溝通,然後試圖在一個限定的範圍裡談論這些問題並找出對應的解決方法。

生活在台灣的大家,肯定都有上傳統市場買菜的經驗,你走進傳統市場跟商家老闆買菜喊價錢時,你講的肯定是台語(閩南語)居多,你不會對他說英文!

你挑著菜在趁斤論兩時,單位肯定是台斤而非公斤(kg),為啥?

因為,你就是在這”傳統菜市場”的領域當中

你不用這些領域專家能懂能談的語言,你很難順心買到好價錢…

回想一下在過去十多年的軟體學習歷程當中,為了學習如何與需求方的理解協作,認真地啃了很多不同的書去學方法,像是:

Use Case Modeling, OOAD, UP/RUP …

典型的Use Case Modelingˊ

這些方法很好,但是他有個問題,就是太多的需求分析師不是IT背景的,要他學著理解UML他一直推三阻四的能閃則閃 ..

好吧,那或許我該試試另外一種簡化一點的,像是:

ICONIX Processing

這方法推出的時間,大概是差不多Agile開始被提出時的變形做法,把BCE Pattern拿來利用,並且盡可能地加入一些頁面流程的元素,讓需求、設計、與開發人員可以用較少的資源成本(尚未寫程式),可以進行交流與討論具體解決方案怎麼設計,可惜這個方法就我理解在台灣也未能大熱,雖然我在我的工作經驗當中有導入過,也做過幾個專案,但平心而論要讓非技術底的人一起加入討論甚至共同繪製與捕捉領域問題,還是很有挑戰。

後來意識到一件事情,軟體發展了幾十年,各種方法如過江之鯽,不管是哪一種方法,始終都缺乏了對於非技術基底的利益關係人的協作面向上的友好,這是一個很大的挑戰 …

還好,在Agile/Scrum/User Story開始盛行起來之後, 這樣的問題慢慢的有一些改善的機會。如果希望能夠比較簡單的方式來捕捉真實業務場景問題,Alberto Brandolini在幾年前嘗試推出他基於領域驅動設計的理解,而設計出的一個協作捕捉問題領域的方法 — Event Storming (事件風暴):

Event Storming for Collaboration to crunch domain problems

通過這個事件風暴的互動協作過程,將重點放在關鍵的真實業務場景事件(Events),以及探索是誰、哪個角色會去經由什麼樣的行為(Command)去產生這些事件,把一系列的事件經由時間軸來排序以 MVP的方式捕捉關鍵要徑串起整個業務流程,之後再將具有相關性的 Command, Events 把它給 :

歸類在一起 , 這稱之為聚合 (Aggregate)

在這些被找出來的Aggregate當中, 他們都有可能是潛在的系統邊界候選人,但我們不需要急著去把邊界就直接切分完,先讓子彈飛一會…

當你捕捉到足夠多的Aggregate之後,你很容易的會對這些Aggregate做劃分,或許你會看到1個Aggregate 就是一個系統,或者多個Aggregate(s)存在於一個系統裡,這些都有可能,端看乎這些Aggregate之間的彼此關係。

在這些聚合(Aggregate)被找出來以後,我們需要再更多的探索究竟圍繞著這些聚合的Command(s), Event(s)的一些細節,於是我們會開始挖掘用戶歷程,然後體現出關鍵的業務場景,而這些業務場景我們把它抽象過後提煉出來的模型就能反映到真實的問題領域,所以當我們談到對於問題領域的捕捉,其實無非就是目的要能提供解決方案的 能力 !

綜觀整個領域驅動設計,其實它涵蓋了兩個層次

  1. Strategic
  2. Tactical Design Pattern

如果在思考問題領域的前期時間,能夠稍微提高一下視角,先別快速進入技術細節時,通過事件風暴來捕捉各種問題領域,我們有機會審視一下究竟哪些的問題領域是最值得投入資源心力,最需要用戰力精良的團隊去實現它的,從而識別出核心問題領域,以及其他次要或者支援領域,並在這個過程當中理解到每個問題領域之間的上下游關係…

而走入到實作階段時,就是進入到廣為人知的Tactical Design Pattern,多數人經常第一次接觸DDD時就被 Entity, Value Object, Factory, Repository給吸引住,然後只關注實作面的程式碼,這樣有點可惜因為你始終不明白他為何會被收歸到一個問題領域,如果你沒能經歷過前面一段的 Strategic領域建模過程。

再說說關於微服務吧 !

大概是2014 ~ 2015開始這個主題熱了起來,很多人開始試著把單體(Monolith)應用給大幅的拆分成多個系統,分散部署,然後通過各種通訊技術面的實作完成服務之間的解構,這非常的理想也恐怖。

微服務,本質上是個分散式系統的互相協作的集合…

我們必須了解到一件事時,就是分散式系統他天生就是所有的元素都是分散的,充滿很多不確定性,你需要盡可能想辦法讓系統在fail時還能降級維運,而不是說保證他不會死掉,而且在多主機環境下你要做冗餘高可用是有些技術挑戰的,包括session,數據存儲,資料同步更新等等議題,一但你的微服務數量龐大之後,你再開啟這些系統資源的過程與管理會是很大的挑戰。

當天的社群夥伴的與會心得是:

微服務的目的是提高內聚力並且增加系統對fail的容忍度,而不是「不能fail」,否則會被無止盡的拆分壓死,因為拆分又不能fail就得要增加redundant,一旦fail之後的M:N條溝通線會怎麼個斷法?如何復原?
要導入微服務前,RD端一定有些DNA得要先培養,例如TDD、unit test、CI/CD….

這都還不打緊,如果你真的一次性的把單體應用拆分成多個服務了,那麼 :

你準備好面對在諸多服務之間的彼此業務關係的交易補償機制了嗎?

你想過如果萬一真的有開放的通訊的API變動時帶來的困擾有想法了嗎?

如果沒有,真心不建議一次性就全面轉型微服務,因為你只是 :

幫你履歷加分,但對問題領域沒能真正解決問題

那麼,可以怎麼幫助你判斷何時該導入微服務?

從價值著手 !!!

通過我們尋找出來的子系統或限界上下文,甚至找到其中的某一個聚合(Aggregate),如果你發現在特定的事件當中他非常的關鍵,會有很高的價值體現,他不能被別的環境因素所干擾,甚至與其他系統之間要盡可能脫鉤,原因是你希望他有非常高的可用性,或者可以快速更換業務功能,這時你把這一個聚合或這一整個限界上下文的子系統給完全的設計成微服務,那麼這一切顯得合情合理。

想像一下雙十一期間,就連個商品清單頁面都可能是個微服務,因為他訪問量高! 或者購物車本身也需要是個微服務 ~

萬一壞掉不給買,這茲事體大了…

當你能確立這關鍵點之後,你還需要思考維運、團隊、程式碼實作上的細節、業務場景搭配,以及需要背後的更多的協作夥伴(網絡、雲服務供應商、第三方ISVs等等),如此你才能說你有足夠的底氣來面對真實環境上線後的挑戰與壓力!

大抵來說,領域驅動設計與微服務的關係其實密不可分,如果你真心想要導入微服務但是卻對領域驅動設計不感興趣,那真的要很謹慎地實施,預祝您good luck。

工作坊回顧 — 事件風暴 領域建模

在第一場的議程結束後,大夥分組拆成了將近10個團隊,Arthur通過範例讓大家快速熱身理解到什麼是events以及進行一個旅遊業的酒店經營業務案例。

很快的每個小組都有自己的領域捕捉的方式,過程中我們通過暫停與分享的方式,讓每一組夥伴都能說說看自己在過程中的體驗。

(照片量真的非常驚人,無法一一貼上來詳細分享,有興趣的夥伴不仿到我們社群去看看! )

在活動的尾聲,我們讓每一組進行回顧會議,分享彼此心得在今天的活動的收穫是什麼。

緊接著把握剩下被場地主人趕出門的風險,再做一個群體大回顧,試圖多一點機會聽聽不同團隊的聲音 ~

總結活動回饋

在當天的活動結束後,我收到一些與會夥伴的心得回饋:

總體來說,我看到了這些寶貴的意見真心覺得舉辦第一次的meetup是值得的,我們需要更多的夥伴的投入,更多有興趣的人一起來嘗試分享,眼下我們即將在2月份開始讀書會了,隨著冬天已過春暖將臨之際,更多正能量與熱忱將會大大的投射出來 ..

熱血,正沸騰著~而你在等什麼呢?

DDD Taiwan 歡迎你的加入

Facebook 社群: https://www.facebook.com/groups/381051212383902/

Facebook粉絲專頁 : https://www.facebook.com/DDDCommunity.tw

Twitter : https://twitter.com/DddTaiwan

也可以關注我個人喔 :D

Facebook : https://www.facebook.com/kim.kao.33

Twitter: https://twitter.com/YiKaiKao