August 05 01:09~02:47
▲圖1：標準版的ezKanban支援四種報表
前言
在外租屋的朋友，如果只租一間房間，一般而言有兩種選擇：套房或是雅房。套房是包含衛浴設備的房間，雅房則沒有專屬的衛浴設備，需要和其他人共用衛浴設備。前者組金比較高，後者比較便宜。
你喜歡套房還是雅房？
如果經濟許可，當然是有專屬衛浴設備的套房比較方便。
但是，從軟體開發的角度來看，軟體開發人員應該更喜歡雅房才對啊！為什麼？ 因為這樣大家才可以共用（reuse）衛浴設備。每一個房間都裝一套衛浴設備，是一種duplicated code，這是一種程式開發的怪味道（bad smells），要加以去除才對。
但是，共用就不能獨立自主啦。如果你要洗澡的時候，別人正在洗澡，你就要等待。上一個上完廁所的人衛生習慣不好，沒有沖馬桶，你上廁所的時候就要幫前一個人善後。
所以，要不要共用，不是只有一個「是否會產生duplicated code」這個因素（force），還有其他條件需要考慮。今天Teddy講一個在ezKanban裡面關於共用與去除duplicated code的故事。
***
標準看板報表
如圖1所示，在ezKanban中，支援以下四種報表：
- Lead Time Distribution Chart（交期分布圖），由GetLeadTimeDistributionChartUseCase負責產生，它透過LeadTimeDistributionChartProjection介面跟資料庫要資料。
- Control Chart（控制圖），由GetControlChartUseCase負責產生，它透過ControlChartProjection介面跟資料庫要資料。
- Cumulative Flow Diagram（累積流量圖），由GetCfdUseCase負責產生，它透過CfdProjection介面跟資料庫要資料。。
- Due Date Performance Chart（到期日績效圖），由GetDueDatePerformanceChartUseCase負責產生，它透過DueDatePerformanceProjection介面跟資料庫要資料。。
因為ezKanban同時支援State Sourcing與Event Sourcing這兩種不同的資料儲存方式，上述因此每一個產生報表的使用案例所使用的Projection介面，各自有兩種實作。State Sourcing的實作使用PostgreSQL資料庫，Event Sourcing的實作使用EventStoreDB資料庫。也就是說，四個報表有八種不同的實作。
***
看板遊戲報表
2021年7月，ezKanban團隊基於原本標準看板的領域模型加以擴充，開發看板桌遊，如圖2所示。看板桌遊支援標準版的三種報表（Lead Time Distribution Chart、Control Chart、Cumulative Flow Diagram），另外增加看板桌遊專屬的Financial Report（財務報表）。
▲圖2：ezKanban的桌遊模組所支援的四種報表
雖然看板桌遊的前三種報表和標準版的程式邏輯很像，但是有少部分不同。例如對於日期的處理，在標準版中報表的日期是領域事件產生的真實時間，但在看板遊戲中，報表的日期是遊戲中的日期，不是真實世界的時間。例如，圖3是看板遊戲的累積流量圖，X軸的時間分別是Day 8, Day 9到Day 18，這是遊戲設計的時間。圖4則是標準版的累積流量圖，X軸顯示的是真實世界的時間。兩個報表可以透過儲存在資料庫中相同的領域事件資料而產生，但關於時間的處理以及報表呈現的方式則略有不同。
▲圖3：看板遊戲的累積流量圖
▲圖4：ezKanban標準版的累積流量圖
ezKanban團隊一開始實作看板遊戲的前三張報表是直接複製標準版的程式碼，加以修改成看板桌遊的報表。因此又增加三個看板桌遊報表的使用案例，以及六支Projection的實作程式。
***
去除重複的程式碼
一開始直接複製原本標準版的程式加以修改，團隊很快就寫好看板桌遊的報表。寫完之後團隊也沒有打算要修改它，因為看板桌遊的需求並不會改變，所以雖然有重複的程式碼，對整個軟體持續開發活動並不會有什麼特別的影響。有一天團隊將開發看板桌遊的經驗整理成論文，寫到處理報表問題的地方，突然覺得：「既然報表邏輯大部分的一樣，是不是可以重構一下，拿掉重複的程式嗎？」
當然可以啊，從寫出Clean Code的角度來看，去除重複性是很基本的要求，於是團隊便安排時間重構這些產生報表的程式。
怎麼重構？首先最大的問題就是看板遊戲的報表顯示的是遊戲中的虛擬時間，因此團隊一開始採用注入一個TimeConverService的作法來轉換時間。如果是標準版的看板，就注入一個NullTimeConverService，如果是看板桌遊的報表，則注入KanbanGameTimeConverService。
但後來ezKanban也重構的「向資料庫要資料」的設計，一開始採用將查詢資料的method寫在一個ReportRepository裡面。後來覺得這樣做不好，因為ReportRepository的介面太肥大，違反了介面分離原則（Interface Segregation Principle）。此外，因為ezKanban也套用了CQRS，在查詢端套用Repository設計模式，容易和命令端套用Repository設計模式產生混淆。因此團隊把查詢端的Repository改為Projection，然後讓一個Projection身上只有一個query method，只負責一種查詢條件（等於套用了GoF的Command設計模式）。
改用Projection之後，為了解決看板桌遊處理時間的問題，團隊又在Projection設計上套了Decorator設計模式，透過KanbanGameDecorator來轉換領域事件的時間。
故事還沒完，除了原本針對State Sourcing與Event Sourcing各有一個Projection的實作，這裡面也有重複的程式碼。從產生報表的角度來看，原本Projection的設計耦合了以下兩種責任：
- 責任1：從State Sourcing資料庫或是Event Sourcing資料庫找資料的責任。
- 責任2：找到資料資料（找出的資料是一堆領域事件），利用這些領域事件產生相對應的報表。
不管是State Sourcing或是Event Sourcing，產生報表的邏輯（責任2）都是一樣的，因此團隊又針對責任1設計一個ProjectionPeer介面，讓責任2的程式碼只要在Projection中維持一份即可。至於每一個Projection要到PostgreSQL資料庫或是EventStoreDB撈資料，只要注入不同的ProjectionPeer實作即可。在這裡，等於又套了Adapter設計模式。
***
值得嗎？
整個重構過程，套了好幾個設計模式，完全去除了重複程式碼，也達到程式碼重用的目的，同時還滿足領域驅動設計、CQRS、Clean Architecture，真的好棒棒啊。
如果真的這麼棒，Teddy就不用寫這一篇文章了。
雖然報表重構的過程還沒結束，但也到了尾聲的階段。回顧整個過程，Teddy學習到一件很重要的事：
針對Write Model的重複程式碼，值得花時間透過重構加以去除。至於Read Model的重複程式碼，除非寫完之後有經常需要修改的可能性，否則重複就重複吧。
***
ezKanban是為了研究與學習而開發的軟體，因此才會設計成「同時支援State Sourcing與Event Sourcing」。因為這個需求，才導致操作資料庫的程式碼出現duplicated code的問題。這個問題，在一般「正常專案」應該是不會出現，因為沒有人吃飽沒事讓自己的商用軟體同時支援不同的儲存方式。
ezKanban為了這個需求，導致整個資料庫存取層的設計變得複雜許多。在一般情況下，在Write Model中，一個Aggregate對應到一個Repository介面；而該介面通常也只需要一個實作，因此不會有duplicated code。在Query Model中，一個查詢對應到一個Projection介面；同樣地，該介面也只需要一個實作，也不會有duplicated code。
所以整個結論就是：
程式碼重用和去除重複性，要看Context來決定。如果鄉民們的專案不需要跟ezKanban一樣同時支援State Sourcing與Event Sourcing（絕大部分應該都屬於這種情況），在資料庫存取層可以用更簡單、更直接的設計就好。
***
友藏內心獨白：套用設計模式的第一個原則就是，不套模式能不能解決問題？
