順序很重要

August 25 17:43~18:21

 

前言

這兩年多和ezKanban團隊一起mobbing，後端套用了Domain-Driven Design（DDD）、Clean Architecture、Event Sourcing、CQRS、TDD、Design By Contract（DBC）、Living Documentation，幾乎全部的後端架構一開始都是Teddy設計的。這原本就是正常現象，因為ezKanban是Teddy帶著學生一起開發的軟體研究專案。

有時候Teddy需要上課無法參加mobbing，課程結束回來之後發現Teddy不在的時候團隊快速完成了一些功能，但是設計方法不是很好，於是Teddy會跟團隊討論一次設計，再看看要如何重購。

***

順序

Scrum有三種角色，Product Owner（PO）、Developer、Scrum Master（SM），用一句話來形容他們的責任分別是：

• PO：Do the right thing（做對的事情）
• Developer：Do the thing right（把品質做好）
• SM：Do it faster（持續改善）

這三件事情，發生的順序是有意義的。首先，要先確保Do the right thing，要了解問題領域中使用者、客戶遭遇到什麼問題？其次，設計出好的軟體來解決這些問題。最後，持續改善整個開發流程。

許多開發人員非常在意電腦是不是最新的，IDE的熱鍵是否用得滾瓜爛熟。這兩件事情，都重要，也都可以縮短開發時間。但是有一件事情比它們還重要，就是你要先確定你做的事情是對的。你的需求、架構、設計，都是對的，否則只是把錯誤的事情做得更快。

***

 

迭代

上述這三件事，它們發生與實踐的過程，並不是線性的，而是迭代的過程。也就是說，先了解需求一點點，然後做點設計、寫點程式，然後改善；然後重複這個過程。Teddy和團隊mobbing的過程，首先強調的一定都是需求，為什麼要做這個功能？先確認需求，然後才討論領域模型與架構要如何滿足這個需求。至於開發流程的改善，工具類只占一部分，它是很重要的一部分但不是最重要的部分。Teddy只會要求IDE基本的功能與快捷鍵要熟悉，開發環境、測試環境、部屬環境儘量自動化與虛擬化。Mobbing的時間，Teddy在意的流程改善，是能不能提升團隊的設計力、讓大家動腦、可以清楚表達一件事。至於IDE熟悉度的提升如果要達到完全不需要使用滑鼠的程度，有興趣的人私底下再自行練習即可。

雖說這三件事是以迭代的情況發生，但還是要注意順序，不要一開始只注意do it faster，也不管打進去IDE裡面的東西到底是什麼，那就本末倒置了。

***

 

友藏內心獨白：垃圾進，垃圾出。

我可能不會用你，Event Sourcing + CQRS？！（下）

August 17 21:54~22:49

▲圖1：Repository介面

 

前言

在〈我可能不會用你，Event Sourcing + CQRS？！（上）〉Teddy談到Event Sourcing在寫入模型（Write Model/Command Side）並不會比State Sourcing要複雜，甚至更簡單。

但事情通常都是有一好沒兩好，寫入比較簡單，讀取就比較困難，今天討論Event Sourcing在讀取模型的情況。

***

跨Aggregate的資料查詢

在套用DDD（領域驅動設計）之後，Aggregate Root負責發出領域事件，然後透過Repository儲存它的狀態。當採用Event Sourcing時，一個aggregate instance在event store中會有一個event stream用來保存它的所有領域事件。每一個Repository（DDD裡面的Repository設計模式）負責儲存與載入「單一Aggregate」，其介面如圖1所示。

圖2為ezKanban系統core domain的領域模型，它包含Board、Workflow、Card、Tag四個Aggregate。現在問題來了：「如何查詢一個Board裡面有多少個workflow？多少張卡片？多少種Tag？」

如果把DDD Repository設計模式定位為「專門在Write Model中用來存取單一Aggregate的介面」，而且Write Model不需要維持「為了查詢而存在的關聯」，那麼在Write Model中，Board並不知道它身上有多少個Workflow以及Tag，而Workflow也不知道它身上每一個Lane有多少張Card。

 

▲圖2：ezKanban領域模型

 

不用維持雙向關聯之後的Event Sourcing更進一步簡化寫入模型，但查詢就比較困難，特別是針對跨Aggregate之間的查詢。如果不管效率問題，開發人員還是可以透過EventStoreDB內建的Projection功能，讀出領域事件然後在記憶體中「拼出」read model，但這樣執行速度顯然會比較慢。所以在套用Event Sourcing的情況下，針對特別的查詢畫面或報表，通常會特別設計一個View Model以加速讀取速度。

在State Sourcing的情況下，如果是使用關連式資料庫，查詢可以直接下SQL找出所需要的資料。但這並不表示State Sourcing就不會有查詢效率的太慢的問題。同樣地，針對個別查詢畫面，State Sourcing也經常會建立Read Model來加速查詢速度。換句話說，額外建立Read Model並不是Event Sourcing的專利，在State Sourcing系統中，下SQL、Join、Create View都是一種產生Read Model的方法。

***

Event Sourcing到底

傳統上在Event Sourcing系統中套用CQRS，Read Model資料庫的選擇可以和Write Model相同或不同（好像是廢話）。例如Write Model如果用EventStoreDB，Read Model可能用關連式資料庫或NoSQL。但是有另一派的做法是：「既然要Event Sourcing，就Event Sourcing到底，Write Model與Read Model都Event Sourcing。」這是什麼意思？請參考〈事件溯源（11）：撰寫JavaScript在EventStoreDB中產生自訂投影〉，Teddy介紹過EventStoreDB可以透過撰寫JavaScript程式讓資料庫自動產生給查詢使用的projection（自訂projection），然後用這些projection來產生Read Model。在這種情況下，Write Database與Read Database就可以合併成一個。

***

 

結論

看到這裡鄉民們可能會覺得：「Teddy你還是沒說Event Sourcing + CQRS是不是比State Sourcing要難啊？」還是那句老話，沒有比較難，只是不一樣。哪裡不一樣：

• 乍看之下，Event Sourcing寫入比較簡單，讀取比較難，State Sourcing則相反。
• 實際上則是「能量不滅」，各有各的困難之處。Event Sourcing不須要設計資料庫schema，感覺好棒棒。但設計資料庫schema的問題並沒有消失，只是轉成設計領域事件schema。

Teddy寫這兩篇文章的目的不是要倡導大家使用Event Sourcing，只是要提醒，它就是一種儲存狀態的方式，它沒有比State Sourcing難。如果你找到適合Event Sourcing的應用場景，使用它可以簡化系統設計。如果你的應用場景不需要記錄所有狀態異動，而且你也不熟悉Event Sourcing，那麼就用已經習慣的State Sourcing就好，不用趕流行。

但是，多了解一種狀態儲存方式也沒什麼壞處，難保哪一天合適的應用場景出現了，此時不知道Event Sourcing可能會設計出過於複雜的系統。

***

友藏內心獨白：學習新技術就是為了未來有能力可以看到forces。

我可能不會用你，Event Sourcing + CQRS？！（上）

August 16 10:03~11:33

▲圖1：Clean Architecture四層架構

 

前言

上周末上完【事件溯源與命令查詢責任分離架構實作班】首發團，有一位認識近十年的老學員告訴Teddy：「這是我上過泰迪軟體所有的課裡面最難的一門課。以前的課我回去都可以直接挑選某部分在工作上應用，這個Event Sourcing加上CQRS我一下子想不到可以用在哪裡。」

Event Sourcing真的比State Sourcing（OR-Mapping）要困難嗎？這次分兩集談一下這個問題，這一集先從寫入（Command/ Write Model）來比較兩者的異同，下一集再來討論讀取。

 

***

只是不一樣

Teddy覺得這位老學員之所以會覺得難，主要的原因是在課程中Teddy把近幾年所學關於Event Sourcing, CQRS, DDD, Clean Architecture的全部重點濃縮在兩天內講完，所以資訊密度比較高。至於Event Sourcing本身Teddy認為並沒有比State Sourcing要難，困難的地方在於你會想應用Event Sourcing的場景通常是在分散式系統或套用微服務架構，是這個「分散式環境」讓你誤以為Event Sourcing比較難，而非它本身真的比較難。

和State Sourcing相比，Event Sourcing只是做法不同，並沒有比較難；它們只是一種儲存系統狀態的方法。

 

***

從Clean Architecture看Event Sourcing

請參考圖1的Clean Architecture架構圖：

Entity Layer：Entity Layer首先反映問題領域的重要概念與關聯，理論上這一層的物件根本不管物件如何儲存。但在程式實作面，Event Sourcing對Entity Layer的實作方式的確會產生影響，但也僅止於影響Aggregate Root，程式撰寫風格要改成如圖2的event sourced coding style：任何改變狀態的public method，都呼叫apply方法，並傳給它一個（或多個）代表狀態改變的領域事件。然後在event handler（圖2中的when方法）中實作程式邏輯。這種程式撰寫風格，也可以適用state sourcing，所以也不是說寫成這樣就一定要用event sourcing。

 

▲圖2：Event Sourced Aggregate Root撰寫風格

***

 

Use Case Layer：請參考圖3，Use Case透過注入的Repository來存取Aggregate，Use Case並不知道所注入的Repository是一個State Sourcing Repository還是Event Sourcing Repository。也就是說，是否採用Event Sourcing並不會影響到Use Case。

▲圖3：Use Case範例

***

Interface Adapter Layer：請參考圖4，Interface Adapter Layer左方是State Sourced Repository的實作，右方是Event Sourcing Repository實作。從寫入（Write Model）的角度來看，如果是採用OR-Mapping的State Sourced Repository，由於還要寫一堆ORM設定或是下SQL寫入資料庫，實作方式其實比Event Sourced Repository還要複雜，並沒有Event Sourcing的儲存方式比State Sourcing要困難的問題。

 

▲圖4：Interface Adapter Layer與DB & Driver Layer

 

***

DB & Driver：請參考圖4，DB & Driver Layer左方是State Sourced Database，右方是Event Sourced Database。如果左方採用關聯式資料庫，將Aggregate寫入資料庫表格的同時，需要在同一個交易中把領域事件也一併寫入資料庫的Outbox表格。至於右方的Event Store Database，由於只需要寫入領域事件，不需要像關連式資料庫一樣寫入時套用Transactional Outbox設計模式，所以反而比較簡單。

***

結論

經過以上分析，從讀寫分離的角度來看，Event Sourcing在寫入端其實比State Sourcing還要簡單。但就像Teddy經常說的「能量不滅」，寫入比較簡單，通常讀取就比較困難。下一集從讀取模型來比較Event Sourcing和State Sourcing。

***

 

工商服務

最後打個廣告，10月份【領事件溯源與命令查詢責任分離架構實作班】招生中。

***

友藏內心獨白：Event Sourcing是一種第一次會痛，第二次會爽的技術 XDD。

套房還是雅房？

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（絕大部分應該都屬於這種情況），在資料庫存取層可以用更簡單、更直接的設計就好。

***

友藏內心獨白：套用設計模式的第一個原則就是，不套模式能不能解決問題？