l

2021年9月15日 星期三

成本與價值

September 15 18:36~19:02

▲ezKanban 團隊mobbing實況


學員:如何讓整個團隊,包含剛進來的新人,都可以學會用DDD(領域驅動設計)開發軟體?

Teddy:我有一個很簡單且有效的方法,但這個方法就算你知道了你們公司應該也不會採用。

學員:什麼方法?

Teddy:Mobbing,又稱為Mob Programming,整個團隊,包含測試、UI/UX與Product Owner,一起開發軟體。

學員:類似Pair Programming嗎?

Teddy:對,不過是Pair Programming的加強版,不只是兩個人一起開發,而是整個團隊。

學員:這樣的確是很難在公司推行,Pair Programming老闆都覺得成本太高

Teddy:那你們都怎麼帶新人?

學員:我們會指派一位導師帶著新人做一陣子。

Teddy:然後呢?是不是一、兩個禮拜之後就讓新人單飛,然後每天問他進度?

學員:(苦笑)沒有這麼慘啦,有問題還是會回答。

Teddy:軟體開發的成本,其實很難量化。老闆通常只看到「開發人員」的成本,因為這是最直接的成本。但除了直接寫code以外,其他的成本呢?

Teddy:你要不要Code Review?有bug要不要改?要改多久?做出來的東西客戶不要怎麼辦?舊員工離職新員工交接怎麼辦?軟體搞到變成硬體,改不動也沒人敢改怎麼辦?後端、前端、內人、外人互相等對方工作完成怎麼辦?需求不清楚開發人員亂寫怎麼辦?測試團隊自創需求,胡亂回報issues怎麼辦?

Teddy:從精實開發的角度來看,這些都是浪費。很多的等待(延遲)、重工、半成品、過度生產、交接、缺陷、工作切換、重複學習。我不敢說Mobbing可以完全消除這七種浪費,但以我的經驗,這種「看起來成本太高」的開發模式反而能夠消除浪費而降低成本並提高產品的品質與價值。

Teddy:老闆覺得開發成本太高,會不會是因為自身的產品在市場上的價值太低,或是想要犧牲品質來拉低成本,所以任何提高品質的活動都會被認為是增加成本。不管如何,這有可能是對於自己產品的定位不同,產生的價值觀落差。

***

沒有銀子彈,但是有高科技武器跟二戰時的武器之分。

***

友藏內心獨白:知道了也做不到。

2021年9月14日 星期二

有沒有發出聲音?

September 14 10:25~11:16

▲電影《達摩》畫面

 

幾年前讀了某本與禪學有關的書,書中提到一個公案:

「在深山中有一片茂密的森林,一棵大樹倒下,發出巨大聲響,但沒有任何人聽到。請問這棵樹有發出聲音嗎?」

***

梁武帝

梁武帝是一位篤信佛教的皇帝,在電影《達摩》中他與達摩會面,他問達摩:

梁武帝:「自朕登基以來,修佛寺,造佛像,抄寫經卷,供養僧侶無數。敢問大師,朕有何功德?

達摩:「無功無德。」

***

一棵大樹倒下,它不甘寂寞,怕沒有人知道它輝煌的一生,所以問了大師自己有何功德?

在電影中志公大師對梁武帝說:「皇上本有功德,但常掛口中,要人稱讚,便是刻意貪圖功德。善惡抵銷,也就沒有功德啦!」

***

政客

很多時候,政客為了自己的政治利益,大撒幣搞大內宣,明明沒有任何樹倒下硬是要誇稱自己做了什麼偉大的事。例如:台灣政府購買的疫苗數量已經夠了、廣告說明是劉德華演唱會,現場來的卻是蘆洲劉德華、演講題目是介紹DDD,但實際內容卻是資料庫驅動設計。

正所謂三人成虎,這種似是而非的大內宣,講久了還真的可能有人會相信。反正政客服務的對象原本就不是全體國民,只要能夠騙到「韭菜」就可以了。

梁武帝至少還做了點什麼,但政客型的人,光靠一張嘴騙選票,刻意貪圖功德的本領遠勝於梁武帝。

***

什麼是真的?

什麼是真理?這是一個很困難的哲學問題。樹的確倒下了,但世界上沒有人發現。從人的角度來看,並未觀察的樹倒下,不知道的事情等於不存在,這也是很合理的觀點。

對樹而言,我倒下了有必要到處宣傳讓人知道嗎?

你想要成為怎樣的樹?

***

友藏內心獨白:Quality Without A Name。

2021年9月13日 星期一

Clean Architecture是一種過度設計嗎?

September 13 11:24~11:46


▲恰如其分的設計,還是過度設計?

 

有一位學員問Teddy…

學員:Clean Architecture是一種過度設計嗎?

Teddy:怎麼會這樣想?

學員:我跟同事討論設計問題,同事覺得我們系統不大,如果套了Clean Architecture,這樣來看Clean Architecture算不算是一種過度設計(Over Design)?

Teddy:你知道Mac Pro嗎?

學員:知道。

Teddy:如果買到頂級的Mac Pro,一台要價超過一百六十萬台幣。這麼高的規格,請問你可以說Mac Pro是一種過度設計嗎?

學員:嗯……

Teddy:如果你買了一台頂規的Mac Pro,只是拿它來上上網,寫寫小程式,在這種情境之下你可以說這是一種「過度消費」,因為你買了你用不到的計算能力。但如果你是專業的影音剪輯人士,一台一百多萬的Mac Pro對你而言可能只是剛剛好而已,甚至還會覺得不足以應付你的工作。

***

Clean Architecture是一種過度設計嗎?

領域驅動設計是一種過度設計嗎?

Design Patterns是一種過度設計嗎?

微服務是一種過度設計嗎?

陶朱隱園是一種過度設計嗎?

高鐵是一種過度設計嗎?

以上皆非,它們都只是一種「設計」,至於這種設計是不是過度或是恰如其分,則是要看應用的情境(Context)而定。

一個事物的含意,必須放在特定的情境去解讀才有意義,才可以避免產生誤會。

***

友藏內心獨白:這就是DCI。

2021年9月10日 星期五

領域驅動設計學習筆記(22):貧血模型與充血模型(下)

September 10 03:38~04:58

▲ezKanban的Board Aggregate套用DCI之後,可以動態指派新的角色給它,以便獲得新的行為能力。


阿嬤的物件導向

DCI架構(Data, Context, Interaction)由Trygve Reenskaug和James O. Coplien所提出,這兩位都是軟體界的名人,前者是MVC(Model-View-Controller)架構發明人,後者是模式與敏捷領域的大師。Teddy今年6月曾介紹過DCI並應用它來重構DDD Aggregate:

***

傳統認為好的領域模型應該設計成充血模型(Rich Domain Model),物件身上封裝著資料與操作該資料的商業邏輯,程式比較容易閱讀與維護。貧血模型(Anemic Domain Model)則被認為是不好的物件導向設計,它將商業邏輯從物件身上抽離出來,物件行為被降級成單純的資料庫操作,因此導致商業邏輯不清、系統難以維護。

Coplien 在介紹DCI的演講中曾說過:「傳統物件導向將資料與行為封裝在一起的做法,是你阿公時代的物件導向技術。」他建議採用DCI架構,將系統區分為DataContextInteraction。DCI架構主張物件的行為,必須要放在特定的使用案例(Use Case)裡面來解讀,才能夠理解其意義。

舉個例子,「人」這個物件,具備「唱歌」的行為。但當一個人在唱歌的時候,到底代表什麼意義,必須從使用案例中去理解。你在KTV唱歌、在學校朝會唱歌、在當兵的時候唱歌、在求婚的時候唱歌、在失戀的時候唱歌、在遊覽車上唱歌、在無人的海邊唱歌、在選秀節目中唱歌、在監獄裡面唱歌,意義可能完全不同。在DCI架構中,將這些不同的使用案例稱為Context(情境、脈絡、上下文)

人這個物件,只需具備資料(Data)即可。至於人到底具備哪些行為,則是在某一個特定Context中,由Context將所需行為動態「注入」到人身上。一個Context經常需要協調多個物件一起工作,這個協調的動作在DCI架構中就稱為Interaction(互動)。

***

何處惹塵埃

上一集,Teddy將「Object is a poor man’s closure, and closure is a poor man’s object.」改寫成「貧血模型是富人的充血模型,充血模型是富人的貧血模型 。」不少鄉民不知道Teddy在瞎說什麼。

為什麼說貧血模型是富人的充血模型?從DCI(富人)的角度來看,貧血模型就是資料物件(Data Object),物件的真正行為延後到執行期間再由Context指派給它。所以,你希望物件有什麼行為,沒問題,爸爸(Context)都可以指派給你。這麼豐富的行為,領域物件還能不「充血」嗎!

為什麼說充血模型是富人的貧血模型?充血模型最佳代表,就是DDD的領域模型(Domain Model)。在DDD中,領域模型主要由一堆充滿行為的Entity、Domain Service、Value Object所構成。其中若干個Entity與Value Object依據商業規則被迫「群聚在一起」形成Aggregate(聚合),並從中找一個Entity出來當「大股頭」(Aggregate Root)號令這個「部落」(聚合)。

客戶端(漢人、老外)只可透過Aggregate Root存取內部的Entities或Value Objects,因此Aggregate Root身上會有很多行為,更是充血到爆。為什麼Teddy會說這些充滿行為的領域模型是「富人的貧血模型」?因為這些行為都是在編譯期間(Compile Time)就已經決定了,因此雖然從傳統物件導向的角度來看它們的血量都很足夠,但從DCI(富人)的角度來看,它們也只是另類的貧血模型罷了。

***

結論

世事無絕對,端看造化而定。

***

友藏內心獨白: 統領埔到底要租給誰,搞得我好亂啊 XD。

2021年9月9日 星期四

領域驅動設計學習筆記(21):貧血模型與充血模型(上)

September 09 07:29~8:30

▲Pascal這種身材應該算是充血模型,把房子都壓垮了還不充血嗎 XD


緣起

幾天前在臉書DDD台灣社團看到有人問「貧血模型」與「充血模型」的問題,問題大意如下:「假設有一個Product Entity,針對該Entity實作查詢產品功能。」

方法一:將查詢功能做在Product身上

public class Product {

private final ProductRepository repository;

public Product (ProductRepository repository) {

    this.repository = repository;

}

public Optional<Product> getProductByName(String productName) {

      return repository.findByName(productName);

}

}

***

方法二:將查詢功能做在Use Case身上

public class GetProductUseCase {

private ProductRepository repository;

public GetProductUseCase (ProductRepository repository) {

    this.repository = repository;

}

public void execute(GetProductInput input, GetProductOutout output) {

      output.setProdeuct(repository.findByName(input.getProductName()));

}

}

***

發問者認為:

  • 方法一的Product有getProductByName這個「行為」,感覺符合充血模型(Rich Domain Model)的定義。但是,讓Product直接耦合Repository好像又不太對。
  • 方法二將getProductByName從Product身上拔除,升等為GetProductUseCase,拿掉Product對Repository的依賴。但是,如此一來Product身上就光溜溜沒有行為,變成Martin Fowler所說的貧血模型(Anemic Domain Model)

到底要怎麼做比較好?

***

不是貧血、充血的問題

關於上述問題,Teddy覺得發問者所舉的例子本質上和Product Entity屬於充血模型或是貧血模型並無直接關係,而是和CQRS(Command Query Responsibility Segregation;命令查詢職責分離)比較有關。

在方法一的所謂充血模型範例中,Product身上的getProductByName(String productName)方法,是一個Query(查詢,回傳資料但不會改變系統狀態的操作),它本來就不需要也不應該存在Product身上。從CQRS的角度來看,Entity主要是要表達Command(命令,會改變系統狀態但不會回傳值的操作),因為發問者把Command與Query耦合在Entity身上,才會有「將getProductByName放在Product身上讓Product產生對Repository的依賴」的困擾。

方法二將getProductByName升級成GetProductUseCase,它現在變成一個代表Query的使用案例,如此一來實現了CQRS。把getProductByName從Product身上拔掉,並不會讓Product變成貧血模式,反而可以讓Product專心去負責原本應該表達的「Command Model(或稱為Write Model)」。這才是DDD(領域驅動設計)要套用的地方,應用在Write Model,而不是在Read Model。

在發問者所舉的例子中,Product就只有Query而有沒任何Command,所以將Product的Query拔掉之後,Product身上就沒有其他行為了,才會誤認此時的Product變成了貧血模型。

***

本來無一物

以上情境,讓Teddy想起有一次聽 Kevlin Henney 的演講,他提到一個故事(以下為Google翻譯後經Teddy修改過的中文):.

尊貴的 Qc Na 大師與他的學生 Anton 同行。Anton希望能引起師父的討論,他說:「師父,我聽說物件是很好的東西——這是真的嗎?」Qc Na憐憫地看著自己的學生,答道:「笨學生——物件只是窮人的閉包(closures)。」

被打槍之後,Anton離開了他的師父,回到了他的小研究室,打算研究閉包。他仔細閱讀了整個「Lambda:The Ultimate...」系列論文及其同類論文,並實作了一個帶有基於閉包(closure-based)的物件系統的小型 Scheme 直譯器。他學到了很多東西,期待著告訴師父關於他的進步。

在與 Qc Na 的下一次散步中,Anton 試圖給他的師父留下深刻印象,他說:「師父,我仔細研究了這件事,現在明白物件確實是窮人的閉包。」 Qc Na 的回應是用棍子打Anton,說:「你什麼時候才學得會?閉包是窮人的物件。」

那一刻,Anton開悟了。

Object is a poor man’s closure, and closure is a poor man’s object.

***

下集待續

先講完背景故事,下一集Teddy從DCI(Data, Context, Interaction)的角度,再談貧血模型與充血模型的不同觀點。

***

友藏內心獨白:貧血模型是富人的充血模型,充血模型是富人的貧血模型 。

2021年9月8日 星期三

【還少一本書】Get Your Hands Dirty on Clean Architecture

September 08 20:30~23:34


 

前言

目前市面上Clean Architecture的書,跟日本進口壓縮機一樣,非常稀少。Teddy在2017年介紹過〈[還少一本書] Clean Architecture〉,事隔多年後,今天要介紹剛讀完的另外一本《Get Your Hands Dirty on Clean Architecture》。

這本書只有薄薄的137頁,書中探討實作Clean Architecture遇到的程式實作問題。Uncle Bob寫的《Clean Architecture: A Craftsman's Guide to Software Structure and Design》雖然多達400頁,但書中的敘述比較抽象,實作的程式碼趨近於0。導致許多人讀完《Clean Architecture》之後,在程式實作的時候形成「一個架構,各自表述」的窘境。而「在乾淨的架構上弄髒你的手」這本書,試圖彌補Uncle Bob留下的實作缺口。

接下來Teddy逐一介紹這本書的優點以及可改善之處。

***

優點--單一責任的使用案例類別

這本書的前兩章談傳統階層架構所造成的問題,以及如何透過依賴反轉來解決這些問題。作者在前兩章還沒提到程式實作,而這兩章的大部分內容在Uncle Bob的書中已經說得很清楚。Teddy覺得比較值得注意的一點是,書中第15頁提到:

The use cases are what we have called services earlier but are more fine-grained to have a single responsibility, thus avoiding the problem of broad services that we discussed earlier. (使用案例就是我們之前所說的服務,但更細粒度地具有單一職責,從而避免了我們之前討論的廣泛服務的問題。)

Clean Architecture的使用案例,有兩種常見的實作方式。第一種就是上述所說的broad service,一個service物件身上包含好多方法,每一個方法代表一個使用案例。DDD紅皮書《Implementing Domain-Driven Design》的書中範例就是典型的broad service寫法。

另一種方式就是將使用案例提升為類別,一個使用案例類別只會做一件事,也就是上述符合單一責任原則的fine-grained service。

Teddy自己是採用一個類別代表一個使用案例(fine-grained service)的做法。

***

優點--程式結構

在Uncle Bob書中由Simon Brown所寫的第34章The Missing Chapter,談四種程式碼結構的方式:package by layer、package by feature、ports and adapters、package by component。雖然這個章節畫了好幾張圖來解釋這四種方法,但Teddy覺得書中的描述還是少了一些重要的細節,導致在實作上有太多的可能性。

這個問題其實很容易釐清,講那麼多還不如給一張圖畫出程式目錄結構就搞定了。

……為什麼不給code哩?

而本書第3章則是以實際的程式結構範例重點說明package by layer與package by feature的優缺點,最後給出作者的建議方式:先package by feature再package by layer。

雖然作者沒有針對Uncle Bob原本書中的四種目錄結構方式詳細比較,但至少給了一個還算是非常具體的實作建議。

***

優點--具體的使用案例實作程式範例

本書第4章談使用案例的實作,以實際的程式碼對應到Uncle Bob書中所說的use case input、use case與use case output。本書把use case input稱為input model,並將其包裝成Command物件(可參考書中第37頁SendMoneyCommand程式碼)。

將input包裝成Command是很常見的作法,但這一點與Teddy的慣用做法不同,Teddy使用UseCaseInput類別來實作input。

Teddy在實作Clean Architecture的時候同時套用DDD與Event Storming,在Event Storming中藍色便利貼代表Command,也就是使用者對系統下的命令。有人將Event Storming的Command當成use case input,Teddy則是直接將Command用使用案例實作,而執行該Command所需的輸入參數當成use case input。所以Teddy把Command這個概念保留給使用案例,而不是使用案例的輸入參數。

儘管書中的實作方式與Teddy慣用方式有所差異,但概念上還是一致。

***

本章另外還有四個亮點:

  • 輸入參數驗證與商業邏輯驗證的差異,以及應該在哪個軟體架構階層中去做驗證。
  • 貧血模型(anemic model)和豐富模型(rich model)對於使用案例的實作有何影響?
  • 使用案例的輸出
  • 唯讀的使用案例實作

***

優點—跨層的物件映射(Mapping)

Teddy讀完Uncle Bob的《Clean Architecture》之後將其重點歸納為三個原則,細節請參考〈再談Clean Architecture三原則〉。其中有一個原則叫做〈跨層原則〉,書中關於此原則的實作著墨甚少,只提到當物件跨層傳遞的時候,會使用Mapper設計模式將物件映射成另一種型別。

實務上,也有不少開發人員反對跨層映射,覺得太麻煩,不但沒效益還產生許多類似的重複程式碼。

本書第8章詳細說明No Mapping、One-Way Mapping、Two-Way Mapping與Full Mapping(《Clean Architecture》書中建議的做法)這四種做法的優缺點。作者建議對於web controller layer採用full mapping,但在persistence layer就不建議使用,因為作者覺得開銷太大,不划算。

但這一點Teddy並不同意作者的看法,在ezKanban中,不管是web controller layer還是persistence layer,都採用Full Mapping。雖然一開始需要花時間寫mapper程式,但在後來Teddy不斷重構entity layer的過程中幫了極大的忙。不管entity layer實作如何修改,persistence layer與web controller layer幾乎完全不受到影響。

***

優點—Main Component的實作

Clean Architecture》第26章The Main Component也是有點抽象的一章,書中提到Main Component是「最髒」的元件,而且每一種系統配置都需要用一個Main Component來代表,在實作上有不少讀者不知如何具體落實這個Main Component。

Get Your Hands Dirty on Clean Architecture》第9章則是以具體的程式碼說明Main Component的實作,又彌補了一個《Clean Architecture》書中的一個實作缺口。

***

可以更好

提了這麼多優點,最後談談可以做得更好的地方。

第一點雖然Teddy把它列為缺點,但也可以說是優點。因為這本書很薄,雖然可以很快一窺Clean Architecture的實作面貌,但對於完全沒有學過Clean Architecture的鄉民而言,如果要光靠這本書就「徹底學會」Clean Architecture,恐怕有點難度。Teddy建議搭配Uncle Bob的《Clean Architecture》一起服用,一本學理論,另一本學實作,學習效果更佳。

第二點Teddy覺得比較嚴重,書的標題雖然是「Get Your Hands Dirty on Clean Architecture」,但作者在實作上滿多地方參考六角形架構(Hexagonal Architecture)並使用六角形架構的術語。例如,在第三章程式結構中使用inoutport這些六角形架構的術語,而非Clean Architecture書中採用的術語。雖說Clean Architecture與Hexagonal Architecture大同小異,但兩者所用的術語還是略有不同。所以在一本標榜Clean Architecture實作的書中採用「鄰國術語」,Teddy還是覺得略有不妥。

此外,硬是要用in、out來區分adapter,Teddy也是略有疑慮。作者提到in adapter代表由外部呼叫系統,out adapter代表有系統呼叫外部。例如,web controller是in adapter,repository或persistence adapter是out adapter,這沒問題。那麼Event Bus呢?它有時候是in,有時候是out,要把它放在那個目錄裡面?還是把接收資料的event bus adapter放在in,傳送資料的event bus adapter放在out?Teddy沒有這樣設計過,所以對於這種區分adapter的方法還需要思考一下。

第三點,書中第6章:Implementing a Persistence Adapter的實作建議Teddy不太認同。書中建議在這裡也套用單一責任原則,讓一個Persistence Adapter就只做一件事,例如將Account物件的載入、更新、建立設計成以下三個介面:LoadAccountPort、UpdateAccountStatePort、CreateAccountPort。Teddy比較建議在這裡套用DDD的Repository設計模式,讓一個Aggregate對應一個Repository來處理儲存的問題。

以上述的Account為例,若採用event sourcing來保存物件狀態,根本不會有書中建議的UpdateAccountStatePort與CreateAccountPort介面,只需要save與load這兩個介面。

最後一點,這是一本介紹Clean Architecture實作的書,程式範例理應很乾淨。但書中有部分範例卻「不太乾淨」,例如下圖書中第35頁的SendMoneyService,它應該位於Clean Architecture的Use Case層。直接在它身上貼上@Transactional似乎有跟框架產生耦合的嫌疑。



 

***

友藏內心獨白:值得一讀。

2021年9月5日 星期日

領域驅動設計學習筆記(20):再談Aggregate Root實作

September 05 20:00~21:30


前言

Teddy之前曾用三集談過Aggregate的基本實作注意事項:

後來在今年學了DCI之後,又從DCI的觀點將Aggregate重構一波:

今天要談的問題,在〈領域驅動設計學習筆記(6):Aggregate (中)〉曾經討論過,就是Aggregate Root應該回傳唯讀的內部Entity給客戶端。原本Teddy採用reflection-util這個工具自動產生immutable proxy。reflection-util需要使用JDK 8以及之後的版本,後來Teddy改用JDK 16之後,發現reflection-util不支援Record類別。

Record類別本身就是不可修改,其實不需要幫它產生immutable proxy。但reflection-util以為Record是一般的類別,會試圖幫它產生一個Proxy(透過子類別的方式)。因為Record類別是final,無法產生子類別,所以reflection-util就破功了。

***

替代方案1: 修改 reflection-util原始碼

▲ImmutableProxy類別透過isImmutable方法判斷哪些型別本身就是不可修改的型別


看了reflection-util的原始碼,其中ImmutableProxy類別的isImmutable用來判斷一個物件是否為Immutable,如果是就不需要幫它產生一個Immutable Proxy。由於ImmutableProxy類別本身是final,而且isImmutable又是static,因此只能修改原始碼,把Record加入判斷中,如此一來就可以在Java 16中繼續使用reflection-util

解決了不支援Record的主要問題,又發現reflection-util不認得Teddy自己設計的final類別,如下圖所示:


reflection-util遇到不認識的final類別也會出錯,無法產生Immutable Proxy。

Teddy認為比較好的方式是ImmutableProxy可以接受從外部注入一個isImmutable方法,如此一來便可動態決定哪些類別原本就是Immutable,不需要再幫它們產生Immutable Proxy。

經過一番嘗試之後,雖然可以修改reflection-util,但Teddy不想自己維護一份原始碼,再加上套用Clean Architecture的情況下盡量不要在Entity Layer使用外部函式庫,所以就決定放棄這個方法。

***

替代方案2: 老師傅手工打造Immutable Proxy

reflection-util原始想法是可以幫任意物件產生一個Immutable Proxy,雖然很方便但因為功能很通用所以遇到的問題(挑戰)也比較多。Teddy本來想偷懶直接使用reflection-util,後來念頭一轉想說算了,自己動手幫Aggregate Root打造合適的Immutable Proxy。

先幫鄉民回憶一下ezKanban的領域模型,下圖是Workflow Aggregate類別圖,其中Workflow是Aggregate Root,其他類別是Entity。

▲Workflow aggregate類別圖


如下列所示,Workflow有幾個方法會回傳Lane或是List<Lane>:

List<Lane> getRootStages()
      Optional<Lane> getRootStage(LaneId laneId)
      Optional<Lane> getLaneById(LaneId laneId)

      理論上使用者不可以透過回傳的Lane或是List<Lane>來修改Workflow的狀態,否則便違反了在DDD中由Aggregate Root確保自身狀態正確性的規定。

      為了回傳不可修改的Lane,首先新增一個ImmutableLane,類別讓它實作Lane介面,如下圖所示。

      ▲代表不可修改的ImmutableLane類別

      眼尖的朋友可能看出來了,ImmutableLane套用Proxy設計模式,它包裝一個原始物件(real subject),並且攔截對原始物件的呼叫。在這裡,所有會改變Lane狀態的方法,例如removeLanes()與addCommittedCard(),ImmutableLane的實作直接丟出一個UnsupportedOperationException,透過這個runtime exception用來物件代表不支援此操作。

      接下來只要修改Workflow(Aggregate Root),讓它回傳內部Entity的時候,也就是回傳Lane或List<Lane>,傳回ImmutableLane即可,如下圖所示。

      ▲修改Workflow讓它回傳ImmutableLane

      ***

      最後寫幾個測試案例驗證Workflow回傳的Lane與List<Lane>真的是不可修改的Lane。

      ***

      後語

      「Aggregate Root回傳不可修改之內部Entity的較佳實作方法到底是什麼?」這件事在Teddy心中放了好一陣子,之前一度使用reflection-util但後來因為前述的原因就沒再使用,因此ezKanban現有的Aggregate Root並沒有嚴格遵守這條要求。

      這幾天Teddy之所以會再注意這件事,是因為前兩天ezKanban團隊與OIS團隊一起mobbing的時候,團隊在event handler裡面寫了一段程式碼,類似:

      workflow.getRootStagebyId(stageId).setWipLimit(WipLimit.UNLIMIT);

      原本設定WIP Limit會產生WipLimitSet領域事件,但是系統跑起來之後卻沒有收到這個領域事件。過了一會兒大家才想起來,啊,不可以直接操作Aggregate內部的Entity來改變Aggregate狀態,要透過Aggregate Root來改變系統狀態。所以程式要改成:

      workflow.setLaneWipLimit(stageId, WipLimit.UNLIMIT);

      ***

      人畢竟是人,如果你問Teddy:「客戶端是不是不能直接修改Aggregate內部的Entity來改變Aggregate狀態?」Teddy會不假思索的回答:「是。」但寫程式的時候,有時一恍神就會寫出下面這種錯誤的程式碼:

      workflow.getRootStagebyId(stageId).setWipLimit(WipLimit.UNLIMIT);

      所以,做人還是不要偷懶,乖乖地讓Aggregate Root回傳不可修改的內部Entity就可以避免這種程式錯誤。

      ***

      友藏內心獨白:犯錯是人的天性,能避免的錯誤還是交由系統來處理。就好像「自主健康管理」有用就不需要集中檢疫了 XD。