l

2021年1月26日 星期二

領域驅動設計學習筆記(17):與外部系統的互動

Jan. 26 22:10~22:59

▲ezKanban使用者註冊範例


學員的問題

今天Teddy和ezKanban團隊mobbing的時候,有一位去年上【領域驅動設計與簡潔架構入門實作班】的學員突然傳訊息給Teddy。一開始對方說要詢問anti-corruption layer實作的問題,但依據Teddy多年的經驗,當有人覺得他的問題是A的時候,通常他的問題都不是A,而是X或Y或Z

討論到後來對方給了Teddy一張從網路抓下來的圖如下:


▲圖1:學員用來詢問Teddy的例子,擷取自網路


對方將付款服務定義一個介面,放在application service layer(也就是clean architecture的use case layer)。他的問題是:

  • 當付款成功之後,是否由application service 發出Paid Successfully領域事件?
  • 如果是,但DDD不是提到領域事件是由Aggregate Root所發出,從application service發出領域事件OK嗎?

***

區分不同的視角

Teddy記得Martin Fowler在《UML Distilled》提到,一個class diagram有三個不同的視角(perspective):

  • Analysis
  • Design
  • Implementation

如果讀者把analysis class diagram當成implementation class diagram來解讀,一定會覺得圖中少了很多細節,甚至會誤解這張圖。

同樣道理,這位學員從網路上看到的event storming例子,頂多就是process level的圖,還沒到design level,所以直接用這張圖來推論實作,就可能會造成誤解。Teddy從design level的視角,將圖1重新繪製如圖2。


▲圖2:將圖1加上Aggregate,進入design level event storming


圖2有兩個Aggregate,因為還不知道要叫什麼名子,先用AA和BB代表。圖2的主流程如下:

  1. 使用者執行付款(Pay,藍色便利貼)命令
  2. 該命令送給AA(黃色便利貼)
  3. AA與外部系統(粉紅色便利貼,此範例的外部付款系統為PayPal)溝通付款細節
  4. 如果付款成功則產生Paid Successfully領域事件(橘色便利貼)
  5. 該領域事件引發一條規則(紫色便利貼)—寄送付款成功的信件給使用者
  6. 因而又觸發了寄送Email(Send Email)命令
  7. 以此類推

根據以上分析,很顯然付款服務應該是一個domain service而非application service。AAA呼叫付款服務這個domain service,並依據付款的成功與否送出不同的領域事件。如此一來便回答了學員的問題。

***

友藏內心獨白:視角清楚,思慮也跟著清楚,答案就在不遠處。

2021年1月22日 星期五

愛上Mob Programming(下)

Jan. 21 18:22~19:50

▲喵星人也要一起mobbing


前言

乍看之下,mobbing是一種浪費,整個團隊一起開發卻只用一台電腦寫程式,感覺是把原本可以平行同時工作變成只能循序工作。今天Teddy從敏捷與精實開發的角度來看,為什麼值得做mobbing。

首先,所有的開發工作,不管是多少人一起開發,大致可以分成兩種工作模式:

  • Component Development:開發人員專注於開發軟體系統的某個元件,例如,寫後端領域邏輯、設計資料庫schema與下SQL、寫前端JavaScript、寫CSS。這種模式底下開發人員所完成的工作並不能直接使用,需要經過另一個人整合之後,例如串起前後端,才會變成一個完整的功能。傳統的瀑布式開發,大多採用這種專業分工的模式。
  • End-to-End Development:又稱為feature development,開發人員需要負責整個功能,也就是所謂的全端開發。全端開發工作並不限定一個人的全端,也可以是交由一個團隊來完成。例如Scrum團隊就是一個可以交付功能的跨職能團隊(全端團隊)。

***

單人開發

單人開發是一般人最熟悉的開發模式,又稱為Solo Programming。如果是採用component development的單人開發,所完成的工作並不能直接交付給使用者,也就是無法直接產生價值,還需要靠整合流程將所有的元件合併成可使用的功能。

從精實開發的角度來看,這種模式所完成的工作都是半成品(work in process/progress;WIP),做得越多,只是累積更多庫存,徒增浪費

如果是feature development的單人開發,這個人就是所謂一條龍全端工程師,可以獨立產生價值。好的全端工程師非常難得,可以做到一個人的end-to-end。但人的能力總有侷限,有些全端工程師是屬於比較偏後端的全端工程師,有些則是前端比較強的全端工程師,也有那種前後端都不熟的全端工程師XD。

在這種情況下,全端工程師的產出,就受限於他自己最弱的一環。假設Teddy的後端能力有100分,前端能力只有20分,Teddy的總產能,不是 (100 + 20) / 2 = 60分,而是只有20分。這就是瓶頸,流程中生產力最弱的那個環節將會決定整個系統的輸出

此外,單人開發還會造成維護的問題。如果這個人離職了,他所負責的程式通常連他自己都看不太懂了,更何況要找一個人來交接工作,難上加難,錯誤百出。

***

雙人編程

為了解決單人開發的問題,eXtreme Programming(XP)很早就鼓吹雙人編程或稱為結隊編程的pair programming。兩個人一起開發,一位扮演司機,另一位扮演領航員,兩人彼此互補,兩顆腦袋一起使用,可以減緩單人開發所遭遇到瓶頸的問題。假設採用feature development:

  • 小明:後端能力90分,前端20分,系統產出20分。
  • 小英:後端能力40分,前端60分,系統產出40分。

兩個人一起合作,整個系統的產出是60分。看到這邊你可能會覺得Teddy在莊孝維。小明、小英個別開發,20 + 40 也是 60分啊,而且搞不好個別開發速度更快。

但實際上,個別開發的速度,除了受限於每個人自身的能力,還受到很多因素影響。例如,專注力、解決bug的能力、當下看出設計問題的能力等等。一個人開發經常會陷入自己的盲點,導致被一些很簡單的「低級bug」給困住跑不出來,徒增很多試錯的時間。

雙人編程可以減少上述問題的發生,又可以自然產生一種良好的「備胎效益」—所有的程式碼至少有兩個人以上都有能力開發與維護,萬一人員異動也不至於整個停擺。

但雙人編程也會造成其他問題,例如如何搭配成員。把兩個菜鳥搭配在一起顯然無法減少瓶頸所造成的限制生產力問題,把兩個高手高高手安排在一起,可能大部分的時間都在吵架「華山論劍」,樂於忙著練功卻忘了實際的開發進度。

***

團隊編程

在mob programming的情況下,團隊成員每個人同時間都貢獻他自己最強的能力在同一件事情上面。例如團隊有五個人:

  • 小明:UI/UX擔當。
  • 小華:JavaScript高手。
  • 小英:後端專家。
  • 小龍:新人。
  • 小陳:Product Owner(PO)。

在mobbing的情況下,這五個人一起開發。假設現在要開發ezKanban的使用者註冊功能,如下圖。


▲ezKanban使用者註冊流程


如果是跑Scrum,PO需要先寫好user story,然後在sprint planning meeting帶過來跟團隊解釋。此時團隊可能選擇估算每一個user story的大小,接著再將user story切成tasks。

Spring planning結束後,產出spring backlog並將其布置成task board。然後每天Daily Scrum的時候團隊在task board前面報告三件事並認領新的工作。Sprint結束後還有review與retrospective活動,

如果改用mobbing,因為整個團隊一起開發,所以也就不需要另外再開會。要開發註冊功能,就直接從event storming的圖中選出Register User這個使用案例,如果開發人員對需求有問題,例如:

  • 要如何註冊?在ezScrum保存一份使用者註冊資料,還是結合Facebook、Google、Line的帳號即可?
  • 要不要整合LDAP做到企業內部單一登入?
  • 註冊畫面需要填寫那些資料?密碼的長度有限制嗎?

以往這些問題可能會在spring planning討論,如果沒有討論到,例如要不要支援LDAP,等到實作的時候,開發團隊就必須要再去詢問PO。但PO不一定可以立即被找到,因此就產生所謂等待浪費。也有可能開發人員自作主張,覺得應該要做到很有彈性,所以在沒有詢問PO的情況下自己加入支援LDAP的功能,導致過度設計,等review的時候才發現這個問題。過度設計,或過度生產,也是一種浪費。

在mobbing的情況下,有任何需求面的問題,當下就可以和PO討論,減少大量部必要的浪費。

在開發整個註冊功能的end-to-end過程中,有時候處理UI/UX、有時候處理後端、有時候處理前端、有時候釐清需求,團隊中每一個對該領域最擅長的人都可以貢獻自己全部的力量。當遇到自己不熟的領域,也可以從別人身上學習,逐步加強自己的能力。

至於新人,加入團隊當下就可以有貢獻。因為mobbing的時候大家輪流當司機(拿鍵盤與滑鼠的那個仁),就算自己不知道怎麼寫,導航員也會告訴你怎麼做。這種在工作中學習的模式,可以達到最快上手的目的。

***

單件流

Mobbing可以做到精實開發提到理想工廠單件流的效果,在生產線上,每個節拍時間就有一個工作在每個工作站中流動。不需要庫存,也沒有浪費(假設沒有缺陷XD)。Mobbing與生產線單件流的差別在於,mobbing是整個團隊跟著工作跑,當工作處於開發後端階段,整個團隊就開發後端;處於開發前端階段,就一起開發前端,只有一件工作在每個工作站流動。

Teddy以一個會寫程式的PO的角色,和ezKanban團隊mobbing近七個月,這段時間沒開過以往Scrum裡面的任何會議,但卻比以往任何時間更了解產品開發的進度與品質。

開發軟體,應該和打籃球、打橄欖球一樣,整個團隊同一時間一起在同一個球場打球。現在想一想,這不是再自然也不過的事嘛!

***

友藏內心獨白:用過就知道,說破嘴也沒用。

2021年1月21日 星期四

愛上Mob Programming(上)

Jan. 21 01:08~14:24

▲ezKanban團隊mobbing實況


緣起

約略四年多前Teddy聽指導教授鄭老師提到實驗室開始全面採用mob programming(簡稱mobbing,這是Teddy第一次聽到這個名詞。

如果鄉民們把mob programming丟到Google翻譯,會得到暴民編程的中文解釋,因為mob的英文就是暴民的意思。最近很流行的新聞—美國擁護川普的群眾衝入國會大廈,英語新聞就用mob來指稱這群人。

***

當然mob programming絕對不會是找一群暴民來寫程式,根據維基百科的解釋:

(譯自英文) Mob編程是一種軟件開發方法,其中整個團隊在同一時間,同一空間和同一台計算機上處理同一件事。這類似於結對編程,在結對編程中,兩個人坐在同一台計算機上,並同時在同一代碼上進行協作。通過mob編程,可以將協作擴展到團隊中的每個人,同時仍然使用一台計算機來編寫代碼並將其輸入到代碼庫中。

也就是整個團隊一起用一台電腦同時開發軟體。

Teddy第一次聽到這種作法,腦中的第一個反應是出現黑人問號的畫面。Pair programming很合理,但整個團隊綁在一起用一台電腦開發,真的假的?!

***

初體驗

兩年多前Teddy幫忙帶幾個實驗室的研究生開發看板軟體—ezKanban,採用類似Scrum的方式開發,兩個禮拜Teddy和學生review一次進度,每次review會跟學生討論設計細節,包含design review與code review。雖然Teddy覺得自己已經把話講得很清楚,但常常在下次review的時候才發現學生的實作並沒有真的達到Teddy的要求,所以需要再解釋一次。長期以往雖然還是有迭代與增量,但整個ezKanban的開發進度總是不如Teddy的預期。

約略一年多前有一次機會,Teddy在實驗室跟團隊一起mobbing,那次的體驗並不好。首先,實驗室的空間並不大,Teddy這個人懶散慣了,不太習慣幾人擠在一個沒有方便伸展與走動的空間。其次,Teddy年紀大了,雖然實驗室mob環境有一台65吋大螢幕,但Teddy看著這個螢幕還是有點不太習慣。寫到這裡Teddy才突然想到,不一定是螢幕的問題,也有可能是實驗室椅子太難坐的關係。畢竟平常在家裡工作,Teddy坐的都是Herman Miller Aeron的高級人體工學椅XD。

總之Teddy的第一次mobbing經驗並沒有激起到自己繼續跟學生一起mobbing的想法。


▲要價不菲的人體工學椅

***

疫情的正面影響

為了Clean Architecture與領域驅動設計(Domain-Driven Design;DDD)課程的教學需要,Teddy自己也開發一套看板系統—cleanKanban,但因為Teddy前端不熟,所以cleanKanban一直就只有後端。

去年七月初暑假的時候,Teddy覺得這樣下去也不是辦法,ezKanban團隊開發一套看板系統,Teddy自己也開發一套。ezKanban團隊的前端做得還可以,但後端還差很多。Teddy的cleanKanban剛好相反,後端好棒棒,但前端……醒醒吧,你根本沒前端啊!

因為新冠肺炎疫情的關係,人們開始廣泛接受以線上活動取代實體活動。Teddy也受到這個正面的影響,去年七月暑假剛開始,Teddy決定把cleanKanban合併到ezKanban裡面,並且跟ezKanban團隊一起mobbing。但Teddy採用skype遠端連線的方式,ezKanban團隊在實驗室mobbing,並分享桌面給Teddy。如此一來,Teddy不用出門,可以舒舒服服坐在家裡的電腦前面玩貓兼用嘴吧寫程式

有此工作環境,夫復何求!

▲Teddy在家裡遠端參與ezKanban團隊的mobbing實況


***

全新的體驗

換個合作模式之後,去年暑假ezKanban進度大爆發。Teddy覺很棒,於是暑假過後繼續跟學生約定每周mobbing的時間。

▲上學期ezKanban團隊mobbing時間表


從去年至今Teddy已經連續和ezKanban團隊mobbing了近七個月,每周平均約20小時,累積mobbing時數應該已超過500小時。

下一集Teddy從敏捷與精實開發的角度來細談為什麼mobbing是一種好的開發模式。

***

友藏內心獨白:看似浪費實則精實。

2021年1月19日 星期二

領域驅動設計學習筆記(16):領域模型要放什麼東西?

Jan. 19 10:00~11:07


客人的問題

上周末在【領域驅動設計與簡潔架構入門實作班】有學員問Teddy…

學員:DDD的building blocks包含Entity、Value Object、Aggregate、Service、Repository、Factory等,為什麼你的domain model裡面沒有畫出Repository?

Teddy:為什麼要在domain model畫Repository?

學員:因為我們要「派工」啊。

Teddy:派工 ?!

學員:對啊,我們要畫設計圖,然後派工給工程師去寫程式。

***

領域模型作為瞭解問題的工具

領域驅動設計是透過「建立領域模型」來驅動整個軟體開發設計的方法。模型屬於solution domain,如果採用最常見的物件導向分析設計方法,領域模型的主角就是代表問題領域裡面重要概念的「物件」。

例如,開發看板系統,在「看板系統」這個問題領域中,重要的概念包含Kanban Board、Workflow、Stage、Swimlane、Kanban Card、WIP Limit、Flow、Lead Time等,它們自然成為領域模型的當然候選人。

你在跟看板的領域專家討論問題時,會出現Repository或Factory這種概念嗎?應該不會吧!所以,你不會在領域模型看到它們。

***

但是我要派工啊

好、好、好,Teddy知道你要派工。領域模型首先作為了解問題領域的分析工具,最後當然還是要用程式碼實作出來。傳統OOAD透過「模型轉換」過程,將分析模型轉成設計模型再轉成實作模型。但DDD希望針對同一個bounded context,整個開發過程就只有一個模型,用這個模型作為領域專家與團隊的通用語言(ubiquitous language),最後再將通用語言用程式碼實作出來,達到ubiquitous language in code的境界。

想要將DDD的領域模型再轉成詳盡的設計模型然後拿給程式設計師去寫程式(完成一個派工的動作XD),是waterfall的做法。如果號稱使用DDD但還是採用這種做法,代表團隊根本沒有共通語言,所以才需要使用另一種語言(派工文件)來溝通

看到領域模型中的Aggregate,自然就知道需要搭配一個Repository來負擔持久化(把Aggregate狀態存到資料庫中)的責任,根本不需要在領域模型裡面表達這種關係。

***

DDD為什麼流行?

DDD藍皮書2004年出版至今也過了10幾年,為什麼近幾年才流行?Teddy認為除了很多人想透過DDD來開發微服務系統以外,另一個原因就是DDD、Event Storming與Clean Architecture、TDD這些做法全部加起來,非常適合用來作為落實敏捷開發的一種實踐方法,符合目前整個軟體開發的主流做法,做得好可以讓你的軟體變軟。

軟體變軟,才能夠支撐公司業務變得更敏捷(靈活)。DDD是domain-driven design,不要搞成document-driven design。

***

友藏內心獨白:軟體開發的特性就是「按圖施工,保證不成功。」

2021年1月10日 星期日

領域驅動設計學習筆記(15):拿掉領域事件所造成的跨Bounded Context原始碼依賴關係

Jan. 10 22:29~23:59

▲圖1:ezKanban三個bounded contexts之間訊息流動方向


領域事件造成的原始碼相依性

上一集〈領域驅動設計學習筆記(14):依據領域事件流動方向調整Bounded Context的依賴關係〉提到依據領域事件流動方向將ezKanban的bounded context依賴方向由原本的:

  • Team—>Account
  • Team—>Board

調整成如圖1所示的:

  • Team—>Account
  • Board—>Team


請參考圖2,以UserRegistered領域事件為例,當使用者成功註冊之後,系統會自動幫該使用者建立一個預設的Team(團隊),當使用者登入系統之後,就可以在這個預設的團隊裡面新增Board(看板)或Project(專案)。

▲圖2:UserRegistered領域事件由Account bounded context傳遞到Team bounded context

ezKanban雖然切成三個bounded context,但目前採用Monolithic(單體)佈署方式,因此三個bounded context透過一個共享的in memory event bus來發送與接收領域事件。圖3展示位於Team bounded context的event handler—NotifyTeam程式,它監聽UserRegistered領域事件,當該事件發生時,呼叫CreateTeamUseCase幫剛註冊的使用者新增一個預設的團隊。


▲圖3:NotifyTeam事件處理程式

看到這裡鄉民們應該就很清楚,基本上Account與Team是兩個獨立的bounded context,彼此之間只有在runtime(程式執行期間)透過領域事件產生相依,compile time(編譯期間)原則上是不需要產生原始碼相依性。但因為一開始Teddy與ezKanban團隊偷懶的關係,讓Team直接去聽Account的UserRegistered領域事件,因此Team需要將UserRegistered類別import進來,所以產生Team對Account bounded context的原始碼依賴。

***

拿掉原始碼依賴

拿掉Team對Account bounded context的原始碼依賴也不會很麻煩:

  1. 設計一個RemoteDomainEvent類別,用來代表跨bounded context的領域事件,並將它放在所有專案都會參考的共用模組裡面。
  2. 不要直接把UserRegistered類別傳給Team,而是把UserRegistered「序列化」(例如轉成JSON格式)之後用RemoteDomainEvent將它包起來再傳出。
  3. Account不再監聽UserRegistered領域事件,改監聽RemoteDomainEvent。當收到RemoteDomainEvent之後,將其內容打開判斷是否為UserRegistered領域事件,如果是再執行原本的事件處理程序。


請參考圖4,NotifyAccount是位於Account bounded context的事件處理程式,它監聽自己的UserRegistered領域事件,並將其轉成RemoteDomainEvent。


▲圖4:NotifyAccount事件處理程式


圖5展示新的NotifyTeam事件處理程式,它改成監聽RemoteDomainEvent,並依據事件的tag與事件名稱將其轉交給合適的事件處理程式來處理。


▲圖5:新的NotifyTeam事件處理程式


將原始碼相依性徹底拿掉,從佈署的角度來看,要從Monolithic(單體)轉成Microservices(微服務)對系統架構來講要改動的幅度也就比較小,增加佈署方式的選擇彈性。

***

依賴依然存在

最後提醒一點,Account與Team這兩個bounded context,從Context Map的角度來看,應屬於Customer/Supplier的上下游關係,所以兩者之間還是有依賴關係,只不過這個依賴關係由原始碼依賴改成符合真實世界狀況的執行期間的訊息依賴。如果Account的UserRegistered領域事件介面改變,還是有可能會導致Team發生執行期間錯誤(runtime exception)。

***

友藏內心獨白:動態比較有彈性也比較容易出錯XD。

2021年1月8日 星期五

看懂一本書

Jan. 08 16:47~17:58


看完一本書

Teddy在北科上課的時候,經常會告訴學生利用研究所求學期間培養一種學習體驗:「把一本專業書籍從頭到尾讀完、讀懂」

對軟體開發這種知識工作者而言,學習速度就是軟體開發的瓶頸。如果在求學階段就具備「看懂一本書」的能力,畢業之後面對各種新知,學習起來也就不會覺得特別困難。即使覺得困難,也不會覺得是一件不可能的任務,因為你曾經達成過這種任務,體驗過看懂一本書的Quality Without A Name。

***

打賭

去年秋天開學的時候,Teddy問修「敏捷與精實軟體開發」課程的同學有沒有人曾經把一本專業書從頭到尾讀完的經驗?班上只有一位同學舉手。Teddy問他,你讀完的是什麼書?他說:「Clean Architecture」。

Teddy跟這位學生說:「我問你一個Clean Architecture的問題,如果你答對,這門課就直接及格,可以不用來上課。如果答錯,就退選,好不好?」

同學拒絕了。

Teddy想要測驗一下這位同學對於自己「看完一本書」的信心指數,因為Teddy所謂的「看完一本書」,是指「把這本書看懂」,不是表面上把書「看完(翻完)」而已。

***

怎麼算是把書看懂?

「看懂一本書」是一個很抽象的概念,而且看懂的層次也會隨著讀書的次數與自身體驗的增長而有所不同。Teddy有幾個自己土法煉鋼的方法:

  • Teddy在「增進學習力的三個練習」提到,可以透過了解專業名詞定義、有能力用一般人可以聽懂的比喻來解釋專業術語、看到解決方案之後,可以反推論出這個解決方案所要處理的問題是什麼(problem before solution,問題先於解決方案)這三個方法來讀書。
  • 自問自答,問自己為什麼。例如,學習Design Patterns的時候,學到Adapter設計模式,可以問自己:為什麼要用Adapter?Adapter要解決什麼問題?沒有Adapter之前的世界長什麼樣子?遇到相同問題,除了Adapter以外,還有哪些的解決方案?是什麼因素導致你選擇Adapter而不選擇其他解決方法?每問一個問題,就等於幫自己的知識累積一個層次,問題問多了,也就很難遇到可以把你問倒的人。
  • 實踐。書上很多知識,如果只是透過「腦袋中的理解力」去學習,哪只是學了一半,另一半落實(實作)能力還是要靠自己動手。建築師Alexander說:「A pattern is a process and a thing」從智力上去理解一件事,只是知道這個Thing,要動手去做,才能了解Process。特別是對於軟體開發人員而言,「知道」設計模式、單元測試、CI/CD、TDD、DDD、Clean Architecture、CQRS、微服務,但卻沒有動手做過,這樣的知道,不能算是真的知道。
  • 多看幾遍 (迭代)。好書,不是一次就可以讀完、讀懂。所以,多看幾遍,隨著自己的生活體驗不同,每次都可以看到不同的東西。

***

再續前緣

昨天Teddy在北科的課程期末考,沒想這位剛開學時說過讀完Clean Architecture的這位同學念念不忘這件事,希望Teddy下禮拜學期最後一週可以問他一個Clean Architecture的問題,他想挑戰自己的學習成果。

就如他所願,下禮拜問他一個Clean Architecture的問題。鄉民們可以預測一下,同學會不會答對呢?下周在「搞笑談軟工FB社團」公布對決結果。

***

友藏內心獨白:沒賭注就不刺激了啊XD。

2021年1月5日 星期二

領域驅動設計學習筆記(14):依據領域事件流動方向調整Bounded Context的依賴關係

Jan. 05 13:45~17:38

▲事件流動方向也代表bounded context之間依賴的方向


今天談一個開發ezKanban時,只專注在core domain而沒有同時關照到context map所踩到的坑 。


背景

ezKanban目前有四個Bounded Contexts:

  • Account:負責註冊。
  • Team:負責管理團隊、專案、以及看板的使用權限。
  • Board:負責表達看板中的工作流(Workflow)以及卡片(Card),此為ezKanban的核心領域(Core Domain)。
  • Report:負責產生累積流量圖(Cumulative Flow Diagram;CFD)、交期分布圖(Lead Time Distribution Chart)、控制圖(Control Chart)等圖表。


這幾天ezKanban團隊正在開發Add Member To TeamAdd Member To Board的使用案例,原本的設計Add Member To Team屬於Team Bounded Context,而Add Member To Board則是屬於Board Bounded Context的功能,如圖1所示。

▲圖1:Team與Board Bounded Contexts的domain model(部分)

***

問題

Add Member To Team做完之後緊接著要做Add Member To Board,此時發現:

  • Board member必須是team member,因此Add Member To Team需要接受前端傳來的List<Team Member>當作參數。
  • Team bounded context的Team member被移除之後,很顯然地Board bounded context的board member也要被移除。
  • 因為Team與Board屬於不同Bounded Context的不同Aggregate,因此彼此之間的狀態同步要透過領域事件達到最終狀態一致性。

到目前為止看起來都沒什麼問題,問題出在:

  • Team會去聽Create Board所產生的BoardCreated領域事件,以便在它身上加上一個Board物件,作為在團隊儀表板功能顯示給使用者看。
  • Board也要聽TeamMemberRemoved領域事件,以便將自己身上的Board member移除。

如此一來,Team和Board這兩個bounded context便產生循環參考

***

真理之源 (Source of Truth)

Team和Board因為領域事件產生耦合,在分散式系統中,可以在它們兩個之間架上Message Queue,以隔開兩者的直接相互參考。這樣做程式可以動沒問題,但這個現象讓Teddy思考:「兩個Bounded Context互相參考,是否意味著Board bounded context裡面的board物件,應該移到Team bounded context裡面?」

ezKanban的開發順序,先從Board bounded context這個core domain開始,此時主要關注點是工作流程是否可以表達問題領域的各種狀況,以及卡片的設計與流動,等於乎應看板的三個核心原則:

  • 視覺化
  • 限定WIP
  • 管理工作流

所以一開始代表「看板」概念的領域物件—Board被設計放在Board bounded context,等到board bounded context基本功能完成之後,團隊才開始實做Team bounded context,一直到實作至Add Member To Board才發現上述相互參考的問題。

Board這個概念,原本在Team bounded context與Board bounded context都存在,這沒問題。ezKanban的問題在於:「新增Board的時候,這個代表Board資料的Source of Truth應該要存在Team bounded context,而不是存在Board bounded context。」為什麼?現在想想也很簡單,因為從使用者操作ezKanban的時間順序來看,使用者是先在Team bounded context新增一個Board,接著才進入這個Board去設計工作流程與卡片,如圖2。


▲圖2:Team bounded context設計好之後,很明顯可以看出,Board的原始資料應該存放在Team裡面

***

友藏內心獨白:訊息流動的方向也要注意。

領域驅動設計學習筆記(13):什麼時候不要用領域驅動設計

Jan. 04 23:14~Jan. 05 00:12

▲照片與內文無關XD


問題

去年(2020)在上【領域驅動設計與簡潔架構入門實作班】有學員問Teddy:「有沒有什麼情況不要套用領域驅動設計(Domain-Driven Design;DDD)?」

***

問題領域

從問題領域(Problem Domain)的角度來看,Teddy認為以下幾種狀況明顯不適用:

  • 問題過於簡單:DDD藍皮書《Domain-Driven Design: Tackling Complexity in the Heart of Software》的副標題已經說明,這是一種解決軟體複雜性的方法,因此如果你要處理的問題很簡單,就不需要動用到DDD。問題是:「你怎麼知道你的問題是屬於簡單或是複雜的問題?」Teddy有兩種判斷的方法:
    • 一個Bounded Context就可以解決:如果你的問題不需要切成好幾的Bounded Contexts就可以解決,通常代表這個問題比較單純,也許用傳統OOAD方式來處理就可以。
    • 屬於Cynefin framework裡面的simple problemCynefin framework是敏捷開發經常引用的一個框架,它將問題分成四種—Simple、Complicated、Complex、Chaotic,如果你的問題屬於Simple類型,也就是事情的因果關係非常清楚,那麼有很大的機會不需要動用到DDD就可以把問題解決。
  • 問題夠複雜但屬於非核心領域(Core Domain):有時候你的問題很大且複雜,但是你負責的Bounded Context不是系統的核心,只是Generic Subdomain,例如權限管理。在這種情況下,就不需要堅持一定要使用DDD。
  • 缺少領域專家配合:DDD強調開發團隊與領域專家密切合作,如此才能建立合適的領域模型與通用語言。如果你的專案缺少領域專家的密切配合,很難發揮DDD的最大藥效。
  • 查詢功能:依據CQRS的做法,只有在Command端(會修改系統狀態的使用案例)才需要套用DDD。如果是不會改變系統狀態的Query(查詢功能),則不需要設計領域物件,直接從資料庫「生出」前端所需的Read Model或稱為View Model即可。因為查詢不需要領域物件,因此也就不會使用到DDD。

***

解決方案領域

從解決方案領域(Solution Domain)的角度來看,Teddy認為以下幾種狀況代表團隊的技術還不成熟,也許需要練功一下,或是找技術專家一起配合開發,否則斷然在專案上採用DDD,可能會採不少雷且只有「事倍功0.1」的產出:

  • 不懂如何建立領域模型:DDD的一個重點就是透過領域模型作為通用語言的骨幹,這個領域模型可以是物件導向模型、函數模式或程序模型,但一般比較常見的還是物件導向模型。以物件導向模型為例,既使在台灣業界,不少程式設計師最熟悉的還是資料模型,或是透過使用者介面來塑模領域物件,這樣做出來的領域物件,應該是很難達到Ubiquitous Language in Code的標準。
  • 沒寫自動化單元測試:在建立領域模型與達到Ubiquitous Language in Code的旅程上,經常需要不斷調整領域模型,甚至Bounded Context的邊界也可能會略作調整。在這種情況下,如果沒有自動化單元測試(use case level與method level的單元測試)作為安全網,很難在一定的成本之下持續精進領域模型。

***

代價

引入任何新的方法,都有適合與不適合的Context,以及相對應要付出的代價。Teddy認為DDD整套用下來,的確可以達到「讓軟體變軟」的最終目的,但學習門檻還是有的。

在「讓軟體看起來可以動就好」以及「讓軟體變軟」之間,還有很大的取捨空間。要不要用DDD,要怎麼用,還是要看公司、專案、團隊的特性再來決定,不要只聽別人說好棒棒就搶著用。體質不好,可能虛不受補,藥吃多了身體也不見得會有起色。

***

友藏內心獨白:我覺得好的東西你不一定會喜歡啊。