June 22 10:12~10:38
▲小抄第一頁
明天要上第十梯次【敏捷開發懶人包：物件導向技能】課程。這門課主要是介紹物件導向觀念、SOLID原則、DBC，以及OOAD流程快速導覽。以往在課堂上Teddy並沒有講UML，當課程進行時如果有學員不清楚再補充說明。
前陣子參加一場碩士班口試，發生學生有一張基本的UML class diagram畫錯，這件事一直放在Teddy心中。UML 2.5.1版規格書一大本754頁，一般軟體工程師並不用去記住所有細節，但一些常用的基本符號大致上還是需要知道，至少做到團隊溝通時不要造成誤會。
這兩天花了點時間整了兩頁的UML class diagram常用符號，想說明天上課還是稍微補充說明一下，對學員應該還是有幫助。
▲小抄第二頁
兩頁的UML Class Diagram小抄可在此下載，有需要修正或加強之處歡迎提供建議。
***
友藏內心獨白：有點重要又不會太重要。
June 01 09:20~10:26
▲學生發問的問題，圖由學生所繪製
好問題
Teddy這學期在北科教軟體架構課程，設計一個專案給學生練習，題目是：「用DDD + Clean Architecture + TDD，開發看板系統的後端。」這禮拜四在北科上課，學生DD問：「Calculate cycle time這個Command要傳送給哪一個Aggregate？還是應該把這個Command實作成一個Application service？」
由於這整學期Teddy都在教學生如何把Event Storming的產出透過一致性、固定的步驟，在套用Clean Architecture的前提之下，採用TDD方式將設計轉成程式碼，以達到Ubiquitous Language in Code的目的。因此當學生認為他們找不到合適的Aggregate來接收Command，Teddy直覺反應就是：「因為這個Aggregate還沒有存在你們的domain model裡面，是你們還沒開始找，而不是沒有合適的Aggregate。」
後來Teddy詢問每一組，得到的回答大都是「沒有合適的Aggregate，直接把這個Command做成Application service。」只有一組將這個Command送給Workflow Aggregate，但Teddy覺得送給Workflow並不合適，因為Workflow沒有Card移動的資料，無法計算cycle time。
***
公堂之上大膽假設
最後Teddy提議增加Cycle Time Calculator這個Class，由它負責計算cycle time，並寫了一段程式碼給學生參考。
Teddy：Cycle Time Calculator是一個沒有狀態的service類別，service有兩種：domain service與application service，它應該屬於domain service，放在clean architecture的entity層。
學生DD：可是老師你說接收Command的對象是Aggregate，而Aggregate是有ID與狀態的類別。但是Cycle Time Calculator是service，它並沒有狀態，這樣不是違反了之前design level event storming的規範？
討論到這裡Teddy不得不稱讚一下這位同學，因為這個問題Teddy之前也沒想過…
Teddy：將design level event storming轉成clean architecture的程式碼的方法是我們自己定義的，我們可以加上一個規則「Aggregate與Service都可以接受Command」。
這種說法感覺有點硬坳，但乍看之下也還說得過去。
***
忙到忘記
回家之後過了一會Teddy才想起來：「這個問題之前和ezKanban團隊開會時曾經討論過！」當時Teddy告訴團隊：「計算cycle time是在Reporting bounded context，它不是看板系統的core domain。因為它是產生報表的domain，是唯讀的，所以我們不一定要套用DDD或是OOAD的方式來建這個reporting domain，也許可以用transaction script就可以產生報表。」
但後來Teddy沒有進一步與ezKanban團隊review他們實作reporting domain的程式碼，所以細節上他們到底如何實作Teddy也不知道。
***
討論無身分高低
在這禮拜四上課時Teddy曾詢問ezKanban的人如何實作Calculate cycle time？只得到「設計成service」的答案。後來Teddy發表一堆「公堂之上大膽假設」的言論，ezKanban的人也沒跳出來 打槍 提醒Teddy，這個問題之前曾經討論過。
可能學生預設認為上課只是來聽老師開講，把所謂的「正確答案」記下來就好，不要質疑老師，也儘量不要跟老師對上眼、說上話。
但Teddy的課程不一樣，第一個禮拜上課Teddy就告訴學生：「叫我Teddy就好，不用叫我老師。別的課我不知道，但在我的課堂上我們的關係是平等的，不是上下階級。我只是在課題上扮演老師的角色，你們扮演學生的角色，僅此而已。修這門課我會問很多問題，你要願意與我互動，再來修這門課，不然就請退選。」
▲課堂上老師與學生的關係是A還是B？
雖然第一周上課Teddy就把話說得很清楚，但學生心裡還是千百個不願意，可能還是怕被老師擺一道，萬一多說話得罪「方丈」日子就不好過了。但專業討論不應有身分高低，如果學生心中有看法，但礙於身分不敢說，這其實是陷老師於不義，阻礙了課堂上探索知識的機會。
***
反思
敏捷開發強調要透明，唯有透明，探索與調適才可能發生作用。很顯然Teddy與學生之間的互信可能還不夠，導致學生有看法不好意思公開表達。
不過，學生當下沒提出來也不能排除另一個原因，就是學生自己也忘了，根本沒想那麼多。
***
友藏內心獨白：腦補得太厲害。
