領域驅動設計學習筆記（19）：DDD需要套用Unit of Work (UoW) 設計模式嗎？

August 19 22:56~August 20 00:29

 

 

背景說明

昨天Teddy在【搞笑談軟工Facebook社群】提到在DDD中應該是不需要使用Unit of Work (UoW) 設計模式，鄉民A問在DDD不合適使用UoW的原因是什麼？今天談一下這個問題。

***

Unit of Work設計模式

依據Martin Fowler在《Patterns of Enterprise Application Architecture》的解釋，Unit of Work:

Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolutions of concurrency problem. （Google 翻譯：維護受業務交易影響的物件列表，並協調更改的寫入和並發問題的解決方案。）

感覺有一點抽象，Teddy舉一個ezKanban系統的例子來說明Unit of Work。

***

範例說明：ezKanban與看板遊戲

ezKanban是一個採用DDD與Clean Architecture架構所開發的線上同時多人使用看板系統，圖1展示ezKanban的五個使用案例：Create Board、Create Workflow、Create Stage、Create Swimlane、Crate Card。其中Create Board操作Board Aggregate，Create Card操作Card Aggregate，另外三個使用案例則是操作Workflow Aggregate。

▲圖1

 

由於在DDD中Aggregate就是一個交易邊界（transaction boundary），所以每一個使用案例都在各自的交易中處理。從這個角度來看，Aggregate本身就已經是Unit of Work，如果還需要額外套用Unit of Work，就代表有某種需求，需要在Aggregate之外再加上一層，把多個Aggregate放在一個更大的Unit of Work。

***

最近Teddy與ezKanban團隊使用ezKanban系統開發一個新的看板遊戲功能，新寫了Create Kanban Game這個使用案例，請參考圖2。

▲圖2

 

Create Kanban Game的實作方式只是呼叫原本寫好的那五個使用案例，此時有鄉民可能會認為：「是不是應該把Create Board、Create Workflow、Create Sage、Create Swimlane、Create Card放在同一個交易中處理以便確保資料的一致性？」如果真的要這麼做，就有可能套用Unit of Work設計模式。

Unit of Work是把原本不同的工作放在同一個交易（transaction）來處理，這在傳統的CRUD系統（集中式系統）是很常見的需求。但是，在DDD中，不同的Aggregate是透過領域事件（domain event）達到狀態的「最終一致性」（eventual consistency），而不是將這些不同的Aggregate放在另一個Unit of Work中達到ACID。

在DDD中，如果你願意，Aggregate是可以變成一個最小的部屬單位，也就是說Board、Workflow、Card可能被部署成微服務，因此自然也不適合將它們放在同一個Unit of Work（同一個交易）來處理。

***

如果是同一個Aggregate…

後來鄉民B進一步問：「如果是在同一個Aggregate的話，是不是就可以套Unit of Work？」

例如，假設在ezKanban系統中有一個使用情境是要一次新增一百張卡片，實作方式如果是連續呼叫Create Card 使用案例一百次，這樣都是操作同一個Card Aggregate，是不是就可以把這些對於Create Card使用案例的一百次呼叫放在Unit of Work中？

如果是這種需求，乍看之下覺得要用Unit of Work是很合理的。但是，再仔細思考一下，在DDD中「Aggregate形成交易邊界」這個特性，雖然都是相同型別的Aggregate（都是Card），但這一百張卡片是一百個不同的aggregate instance，所以嚴格講起來每一個aggregate instance應該都只管自己的交易。

但是，這樣一來「資料正確性」怎麼辦？Teddy覺得在DDD這頂「大帽子」之下，應該儘量朝向分散式處理、最終一致性、交易補償（錯誤處理）的角度來思考系統的行為與狀態，長期而言會比較能夠得讓系統從分析、設計到實作，保持一致性與完整性。

一旦在DDD裡面採用「Unit of Work將多個Aggregate打包處理」，Teddy大膽假設團隊中就會有人的想要在DDD中做到「分散式交易處理」或是「二段式提交（Two-Phase Commit）」的效果，如此一來思考模式又回到傳統的ACID與集中式系統的模式。

那麼，回到根本的問題，為什要要DDD勒？

***

友藏內心獨白：沒有一定不行，真的想用就用，用了也不用有警察來開罰單。

領域驅動設計學習筆記（18）：學DCI，重構Aggregate ，Part 3

June 24 16:20~17:14

▲圖1 ：在Aggregate Root身上增加這兩個方法以支援動態扮演角色的功能

前情提要

今天是表定介紹DCI與Aggregate連載的最後一集，談如何讓Aggregate具備動態扮演不同角色的能力。

在第一集Teddy提到在DDD的情境之下，Aggregate本身就是若干個小規模使用案例的集合體，所以實務上Teddy認為並不需要像DCI架構所建議的在不同的Context底下，讓Data object動態扮演不同的Role以執行不同功能。但為了學習目的，Teddy還是想辦法讓Aggregate具備這種動態扮演角色的能力。

***

透過Java Reflection實作

ezKanban後端以Java語言開發，Java是一個靜態型別語言，要讓物件動態扮演不同的角色，大概只能透過Reflection機制動手腳。

Teddy的想法很簡單，在Aggregate Root身上增加圖1的兩個方法：

• mixinBehavior：把一個物件加入behaviors list裡面，這個物件可以是任意型別的物件。
• playRole：想讓Aggregate扮演某個角色需要先把該角色透過mixinBehavior方法加入Aggregate Root，再呼叫playRole方法，傳入參數為扮演角色的類別，這樣就可以執行該角色身上的方法。請參考圖2。

▲圖2：測試案例，展示如何動態加入角色到Board Aggregate Root

以下解釋圖2程式碼：

1. 宣告一個任意的類別叫做NewBehavior，它不用實作任何介面，就是一般的Java Class即可。它的身上有一個getBoardInfo方法，回傳一個board id 加上 board name所組合成的字串。這個類別需要獲得Aggregate Root的資料，因此它需要撰寫一個初始化的方法讓Aggregate Root呼叫，並且幫這個初始化方法貼上@MixinInitializer這個annotation。
2. 呼叫board.mixBehavior，把newBehavior當成參數傳給board。這一行等於在程式執行期間動態指派一個角色給Board Aggregate。
3. 呼叫board.playRole(NewBehavior.class)讓board扮演這個新的角色。
4. 最後，可以呼叫到NewBehavior身上的getBoardInfo方法。

▲圖3：測試案例執行結果，當然是綠燈通過

完整的程式還有不少細節Teddy沒有在這裡逐一解釋，不過大方向基本上就是上述的過程。

***

結論

DCI是一個很有趣的架構，而且可以和DDD與Clean Architecture一起使用，讓程式碼變得更乾淨，這是沒有問題的。

由於Aggregate Root實際上某種程度就是一個小的DCI，所以是否需要動態指派角色給它，Teddy目前還不是很確定是否有這個需要，為了學習的目的Teddy還是花了點時間完成這個功能。

最後，Teddy還在持續探討將DCI應用在更大的情境的可行性，例如在Saga pattern中使用DCI，等有結果之後再跟鄉民們分享。

***

友藏內心獨白：動態扮演角色真的滿酷的。

領域驅動設計學習筆記（17）：學DCI，重構Aggregate ，Part 2

June 23 10:03~12:28

▲圖1：Board Bounded Context領域模型，只表示Board與Workflow這兩個Aggregate的關係。

 

前言

上一集介紹DCI架構以及它與Clean Architecture與DDD Aggregate Root的比較，今天說明如何藉由DCI的精神來重構Aggregate Root。Teddy將以ezKanban系統中，Board Bounded Context的Board Aggregate Root為例，介紹這個重構過程。

***

重構前的Board Aggregate

▲圖2：Board重構前程式碼片段，完整的程式有七百多行

 

圖1為Board Aggregate類別圖，圖2為Board重構前的程式碼片段，顯示其資料成員：

• id：繼承自AggregateRoot物件，紀錄Board id。
• nam：紀錄Board的名稱
• teamId：紀錄Board屬於哪個Team
• boardMembers：紀錄Board身上有哪些成員。
• committedWorkflows：紀錄Board身上有哪些Workflow。Workflow是另一個Aggregate，代表看板上的工作流程。
• boardSessions：一位使用者進入Board之後會建立一個board session，透過board session讓位在同一個Board的不同使用者可以互動。

DCI架構要求物件不需要太聰明，只需是Data object即可，至於原先物件身上的方法則抽離出來定義在Role（角色）物件身上。接下來說明如何將Board的角色與資料抽離出來。

 

***

定義Role介面

根據Board所操作的資料，Teddy發現Board扮演了五種角色：

• Content：Board的內容管理，包含board id, board name。
• Dependency：管理Board與其他Aggregate的相依性，在此範例中只有team id。
• Membership：Board成員管理，可以新增、刪除、查詢成員。
• Workflow Relation：Board與Workflow關係管理，可以新增、刪除與調整Workflow順序。
• Collaboration：管理Board身上的同時上線成員。

接著新增KanbanBoardRoles interface，在裡面定義這五種角色，如圖三所示。

▲圖3：用Java interface定義Board的五種角色

***

定義Data介面

定義好角色之後很清楚發現每一種角色只使用到原本Board身上的特定資料成員，因此圖2宣告資料成員的方法很明顯的違反了介面隔離原則。所以針對每一種角色使用到的資料，在該角色內再定義一組存取資料的State介面，如圖4所示。

 

▲圖4：在每一個角色介面內定義一個存取資料的State介面

 

最後宣告一個BoardState介面，讓它繼承每一個定義在Role裡面的Role-Based State介面，如圖5所示。

▲圖5：宣告一個包含所有Board資料的BoardState介面，要用它來取代原本宣告於Board身上的資料成員

***

實作角色

角色介面與資料介面都定義好，就可以撰寫實作角色的程式碼。說是實作但其實並非重頭開始寫，而是重構原本的Board Aggregate。重構的方式很簡單，把原本已經寫好放在Board身上分屬於不同角色的方法，搬移到各個角色身上就差不多大功告成了。Teddy把實作角色的類別稱為Behavior類別，圖6為MembershipBehavior類別程式片段，原本joinAs方法放在Board身上，重構方式只是把它從Board身上移到MembershipBehavior身上。

由於joinAs方法原本定義在Board身上，會存取Board資料與方法，也就是說joinAs依賴Board。資料的依賴關係由第24行的State介面所隔離，行為的依賴則是由第23行MixinContext類別所隔離。State介面已於前述段落中說明，MixinContext留待下一集說明如何讓Data object支援動態扮演角色的時候再解釋。

 

▲圖6：MembershipBehavior類別實作Membership角色介面

***

重構Board

每一個角色都實作完畢之後，最後一步就是重構Board類別。參考圖7：

• 23~26行：讓Board實作圖3所定義的五個角色，以便讓它對外維持原本的介面。
• 28行：用BoardState取代原本的資料成員，此時BoardState相當於DCI的Data。
• 29~32行：圖3定義了五個角色，其中DependencyRole因為只有一個getBoardId方法，所以直接實作在Board身上。其他四個角色各用一個類別實作。29~32行宣告這四個角色的資料成員，Board採用composition-deligation的方式，將客乎端呼叫Board身上不同角色的方法，轉呼叫個別的角色實作物件，請參考圖8。

 

▲圖7：重構後的Board資料成員

 

▲圖8：Board身上的joinAs方法轉呼叫membership角色的joinAs方法

重構完畢後Board程式碼剩下約190行（原本有7百多行）。

***

結論

依據DCI「精神」重構之後，Board Aggregate的責任與介面變得很乾淨，個別角色所負擔的責任其實做程式碼也跑到相對應的行為類別身上，符合單一責任原則與介面隔離原則。可以針對個別行為單獨撰寫單元測試，增加了可測性。

DCI架構還有一個很神奇的地方，就是希望Data object可以在不同的Context（使用案例）中動態扮演不同的角色，以執行不同的功能。Teddy將於下一集說明如何用Java語言在DDD Aggregate中實作這個動態扮演角色的特性。

***

友藏內心獨白：真，單一責任原則。

領域驅動設計學習筆記（16）：學DCI，重構Aggregate ，Part 1

June 22 09:28~11:08

DCI簡介

最近三個月陸陸續續花了點時間研究DCI架構（Data, Context, Interaction），該架構包含三個主要元素：

• Data：資料物件，傳統OOAD或DDD所謂的領域模型物件。DCI認為物件只需要有資料，以及存取資料的簡單方法即可。操作這些資料的演算法（methods），應該從物件身上獨立出來，放到角色（Role）身上。從這個角度來看，Data類似Martin Fowler所說的貧血模型（Anemic Domain Model）。
• Context：實作使用案例的地方，DCI認為，物件的演算法必須放在一個特定使用情境去討論才可知道它的意義，這個情境（Context）就是使用案例。
• Interaction：使用案例藉由指派若干物件扮演不同的角色，並協調物件之間彼此的協作來完成使用案例，稱為互動（Interaction）。角色是一個沒有狀態的物件，有點類似domain service。但在DCI架構中，Data物件可以在程式執行期間動態扮演不同角色以便獲得執行不同演算法的能力。Data物件扮演某個角色之後，該Data物件看起來就變成該角色的型別，可以執行該角色身上所定義的方法。

乍看之下DCI好像把原本富有行為的充血模型，搞成只剩下資料的貧血模型，這不是一種物件導向分析設計的壞味道嗎？其實不然，DCI的倡導者James Coplien認為：「把資料和行為封裝在類別身上是祖父級的物件導向設計方法。」DCI的Data物件在編譯期間雖然沒有行為，但其行為是在執行使用案例時動態由Context所指派。Coplien認為唯有給定一個Context再去解讀物件身上的行為才會有意義，程式也比較容易被讀懂。

***

DCI與Clean Architecture比較

▲圖1：Clean Architecture與DCI對應關係

如圖1所示，把DCI對應到Clean Architecture，Teddy認為Data與Role的實作應該是位在Entity Layer，Context與Interaction則是位於Use Case Layer。

由於Clean Architecture並沒有特別規範Entity Layer的領域物件需要如何實作，所以如果開發人員願意，當然可以用Data與Role來實作領域模型。這就好比可以用DDD的Aggregate、Entity、Value Object、Domain Service來實作Clean Architecture的Entity Layer是一樣的道理。

***

DCI與DDD比較

把DCI和DDD實作融合在一起花了Teddy比較多的時間，主要的問題在於DDD的Aggregate設計模式。Aggregate是一組物件的集合，從中指派一個物件當作Aggregate Root，所有對於該Aggregate內部物件的存取，都需要透過Aggregate Root。Aggregate同時也是交易邊界，同一個Aggregate資料存取必須發生在同一個交易之內，不同Aggregate則是透過領域事件同步狀態，達到最終一致性及可。

若將Aggregate對應到DCI，它到底屬於Data，還是Context？

看到這裡有人可能會覺得：「Aggregate不是放在Entity Layer的物件嗎，那就應該屬於Data啊。」在Teddy實作DDD的時候，的確是把Aggregate放在Entity Layer，但實際上Aggregate Root某種程度扮演了「多個小型使用案例」的角色。因為在設計階段決定Aggregate邊界的時候，很大部分的原因是依據「業務範圍」來決定Aggregate大小。也就是說，從業務需求的角度，若干物件的協作必須發生在同一個交易內商業規則才不會被違反，因此把這些物件放在同一個Aggregate。這樣聽起來，是不是和DCI的Context所扮演的角色幾乎一樣？ 主要的差別在於，Aggregate是靜態的物件協作範圍，DCI的Context則是動態的物件協作範圍。

***

下集待續

先把背景知識介紹完，下一集Teddy將說明如何參考DCI的精神重構ezKanban系統的Aggregate。重構之後的程式變得更乾淨，符合單一責任原則與介面分隔原則。

***

友藏內心獨白：天下事分分合合。

4.99人民幣的學習

June 01 12:48~13:28

▲James Coplien的DCI演講

最近Teddy對DCI（Data, Context, Interaction）架構很感興趣，花了點時間在研究它。相較於其他軟體架構，DCI算是非主流架構，網路上的資料也比較少，主要來自於James Coplien所寫的《Lean Architecture: for Agile Software Development》以及他的幾個演講（可在YouTube上用DCI搜尋）。

前幾天晚上Teddy找到一個張曉龍（中興通訊資深軟件架構師） 在ArchSummit深圳2019的中文演講，講題是〈當DDD遇上DCI〉，引起Teddy的興趣。該演講的錄影被放在中國的「極客時間」上當作一個課程販賣，人民幣4.99。

Teddy沒有微信也沒有淘寶支付，無法購買此課程。後來託Erica請他的中國朋友幫忙，好不容易才買到這個課程，差點上演4.99元逼死英雄好漢的戲碼 XD。

雖然Teddy對DCI研究還不深入，但聽完這個演講，看到演講分享的實作，感覺講者有點胡搞瞎搞。有幾個很明顯的問題：

• 亂用Context：DCI的C是Context，相當於Use Case，也就是Application Service，但講者卻想要用Context來進一步切割Aggregate，並且將C用DDD的Domain Service實作。這一點Teddy覺得有點「張飛打岳飛，打得滿天飛」的感覺。在講者所舉的例子中，除了造成不必要的人為設計複雜度以外（稍後說明），實在看不出什麼好處。
• 未透過領域事件解偶：講者開口閉口解耦合、提高內聚，但範例程式本身就把「轉帳」和「傳遞訊息到手機上面」這兩件事耦合在一起啊。在DDD裡面，這靠Domain Event去解耦合，但講者在拆分Aggregate的時候，不但方式很怪，也壓根沒提到Domain Event，彷彿Domain Event不存在一樣。
• 亂拆角色：講者對於Role（角色）的濫用與誤用到達一個讓人匪夷所思的境界，如圖1所示，講者以一個銀行轉帳的例子來說明他如何在DDD中套用DCI。他讓LocalAccount這個Aggregate Root扮演MoneyCollector, LocalMoneySrc, LocalMoneyDest, AccountInfo, Balance, Phone這五個角色。先不管這些角色的名字取的有多爛，Balance代表帳號餘額，光是Balance被獨立的一個角色這件事就非常詭異。其次，Phone這個角色存在的目的是為了轉帳成功之後通知使用者，為了具備通知的能力，一個LocalAccount需要去扮演Phone，這不是特別詭異嗎？LocalAccount去使用（use）Phone即可，為什麼要去扮演一支電話？難道你為了喝牛奶，需要扮演乳牛的角色嗎？
• 未反映真實事件：Teddy不是銀行這個領域的專家，但轉帳這件事，很明顯的不會只牽涉到來源帳號與目的帳號，至少中間還會有一個Bank的角色。講者號稱要使用DCI來幫助DDD切割Aggregate，但他切了一堆有的沒得角色，反倒是這個重要的Bank角色完全沒有被提到，這不是瞎忙一場嗎？

▲圖1：張曉龍在演講中所展示套用DCI之後的領域模型

***

正確示範

Teddy後來在〈An Empirical Study on Code Comprehension: Data Context Interaction Compared to Classical Object Oriented〉論文裡面看到一個比較像樣的DCI程式範例，如圖二所示。但這樣寫有沒有比較好，要再花時間想一下。

***

友藏內心獨白：胡搞瞎搞，勇氣可嘉。

領域驅動設計學習筆記（15）：領域專家缺貨

April 27 17:12~17:48

▲David West提到在1968年代，銀行的開發人員就是領域專家

不少朋友問Teddy一個問題：「Event Storming工作坊的時候如果領域專家不願意參加，或是勉強參加但卻都在擺爛，被動等著開發人員去問他問題，這樣該怎麼辦？」

這是一個很常見的問題，因為許多公司，特別是大公司，雖然嘴上說導入敏捷好幾年了，但骨子裡還是傳統瀑布是開發方法，客戶（業務單位）與開發人員還是透過中間人所產生的文件來溝通。這個中間人可能是Scrum裡面的Product Owner（PO），或是傳統的專案經理或是系統分析師/商業分析師。客戶（業務單位）認為開發軟體是開發人員的事情，能講的他們都已經講完了，這些開發人員不要三不五時就跑來煩他們，趕快把東西生出來。

另一方面，客戶（業務單位）理論上雖然代表著領域專家的角色，但這並不表示他們有能力和開發人員一起析分商業流程，甚至有些商業邏輯的細節連他們也不十分清楚。再加上客戶（業務單位）的人日常工作量已經很多，自己的事都忙不過來，很難要求他們長時間配合開發團隊持續進行Event Storming並精煉領域知識以及共通語言。

***

所以，如果你的開發團隊有願意一起長時間配合的領域專家，恭喜你你的現況離理想狀況比較接近。如果沒有，也不要灰心喪志，日子還是要過下去。

領域專家「缺貨」怎麼辦？如果真的調不到「貨」，只好讓自己變成領域專家。

幾天前Teddy聽了David West的〈 The Past and Future of Domain-Driven Design〉演講，講者提到在1968年代，銀行的開發人員就是領域專家。在【搞笑談軟工臉書社群】上，有兩位朋友也分享了類似的經驗。

所以，萬一開發專案中真的沒有領域專案，而案子也還是要做下去，考慮訓練自己成為領域專家。這樣做一定會花費比較多的時間，走更多的冤枉路，但總是能緩慢往前移動，總比留在原地一動也不動來的好。

就算團隊中有領域專家，開發人員也不能完全信任領域專家，自己還是要動腦思考，畢竟要將問題領域（problem domain）轉化成解法領域（solution domain）的人，是開發人員，不是領域專家，開發團隊還是要多擔待一些。

***

友藏內心獨白：一個人或是一個團隊的End-To-End，就可以變得很靈活。

領域驅動設計學習筆記（14）：透過合約讓領域模型與通用語言更精確

March 18 21:18~23:13

【圖1】ezKanban的design-level event storming（部分）

工商服務

自學好久的領域驅動設計（Domain-Driven Design；DDD）卻連一個完整的小功能都做不出來嗎？覺得DDD要學得東西太多，總是抓不到重點嗎？想要透過事件風暴（event storming）來塑模業務流程並找出bounded context與aggregate，卻不知如何下手嗎？

你需要真實世界的DDD + Event Storming + Clean Architecture 教學與範例，歡迎參加2021年4月2、3、4日（五、六、日）的【領域驅動設計與簡潔架構入門實作班】課程（已確定開課）。

***

前言

在〈用合約彌補測試案例的不足（上）：撰寫合約〉與〈用合約彌補測試案例的不足（下）：透過合約發現系統行為缺陷〉這兩篇文章中，Teddy談到依合約設計（Design By Contract）在ezKanban系統中的幾個實際應用案例，這一集Teddy要談如何透過撰寫合約找到領域模型與通用語言的行為漏洞。

***

問題敘述

幾天前Teddy去客戶家上DDD與Event Storming企業內訓課程，沒有和ezKanban團隊mobbing。今天mobbing的時候團隊問Teddy一個關於Aggregate行為的問題，請先參考圖1：

• Workflow與Card是兩個Aggregate，前者代表看板的工作流程，後者代表一項工作。
• Workflow包含垂直的工作階段—Stage，與水平的工作階段—SwimLane。
• 使用者新增Card之後，Card被放在Workflow的Stage或SwimLane裡面，使用者可以調整卡片的順序（order），該順序紀錄於Stage和SwimLane身上。
• 由於Workflow與Card分屬不同的Aggregate，因此當使用者移動卡片（Move Card）之後，Card必須通知Workflow卡片已經移動，以同步Workflow身上關於卡片位置與順序的狀態。

團隊遇到的情況是：他們在寫Card.move() 的前置條件（如圖2），原本希望除了檢查參數不是null，以及order >= 0 以外，還能夠檢查order不會大於該卡片所要加入的那個Stage/SwimLane的卡片總數。例如，使用者在To Do這個Stage加上一張卡片，To Do原本已經有2張卡片，move收到的order參數是8，則前置條件檢查失敗。團隊希望能在Card.move()的前置條件檢查這個限制。

【圖2】Card.move方法的前置條件

但是，因為一個Stage/SwimLane身上有多少張卡片的資料是儲存在Stage/SwimLane身上，Card並不知道，所以也就沒辦法在Card.move()方法加上這一條前置條件。

於是團隊問Teddy：「是不是應該把move方法移到Workflow上面，這樣就可以在前置條件中檢查Card的順序？」

***

思考邏輯

這個問題，可以從以下兩點來思考：

1. Single source of truth：Card與Workflow分屬不同的Aggregate，兩者之間透過領域事件達到狀態最終一致性。因此，第一個思考點就是：「關於一張卡片移動至哪個Stage/SwimLane這件事，擁有第一手資訊的人是誰？Workflow還是Card？」Teddy覺得應該是Card。
2. 關於檢查Card順序這件事，除了原本的Card.move()方法以外，另外一個地方就是Workflow.commitCardInLane這個方法，請參考圖3第270~271行，檢查了卡片的順序不能大於現有Stage/SwimLane裡面所擁有的卡片數量。

【圖3】Ｗorkflow.commitCardInLane()方法的前置條件

現在假設一個情況：

• 一張卡片要移到To Do上面的第8個位置。
• To Do身上只有2張卡片。

因此，圖3第270~271行的前置條件會失敗，丟出PreconditionViolationException並且終止程式執行，代表呼叫它的人有bug。呼叫commitCardInLane的人是誰？是CardMoved領域事件發生後的Policy，簡單來說就是Card有bug，這個bug很可能是前端傳過來錯誤的order。

***

如果不希望因為卡片順序有問題就終止整個系統執行，另一種可能性是放寬Workflow.commitCardInLane()的前置條件，把270~271行拿掉，改成在程式裏面（commitCardInLane的method body）判斷，如果條件不成立則丟出一個CardCommittedFailed領域事件，並通知Card執行交易補償（因為Card已經把它自己的狀態改成移動到新的To Do裡面，但Workflow判斷卡片所移動的順序是不合法的，所以請卡片移回它原本的位置）。

如果選擇這種作法，則原本圖1要再加上CardCommittedFailed領域事件，如圖4所示。

【圖4】讓領域事件以及Workflow Aggregate與Card Aggregate的行為更加完整。

***

結論

無論是選擇上述兩種方式的哪一種，系統的行為都因為撰寫合約而變得更精確。最後團隊與Teddy選擇了第二種方式--交易補償，因為這種行為模式容錯能力比較好。

看到這裡如果還沒跑開的鄉民，應該可以發現以下結論：

透過撰寫合約讓領域模型與通用語言更加完整。

***

友藏內心獨白：寫合約可以找到系統行為的漏洞。