四色原型
在企業應用的上下文中，四色原型是領域模型的一種原型，原型的意思是指領域中的任何模型及其關系都可以抽象為“四色原型”。
四色原型可以用這句話進行描述：某個人（Party）的角色（PartyRole）在某個地點（Place）的角色（PlaceRole）用某個東西（Thing）的角色（ThingRole）做了某件事情（MomentInterval）。
圖片示意
名詞解釋
- PartPlaceThing：簡稱PPT，用淡綠色表示，常見的PPT有：部門、崗位、人員、地點、物品等。
- Description：簡稱Des，用淡藍色表示，主要用來對PPT進行描述，常見的Des有：部門類型、崗位層級、人員類型、地點區域、物品分類等。
- Role：用淡黃色表示，主要表示PPT在某個場景下扮演的角色，常見的角色有：財務類部門、管理類崗位、請假者、銷售點、產品等。
- MomentInterval：簡稱MI，用淡紅色表示，主要表示在一刻或一段時間內發生的一件事情，常見的MI有：部門移動、崗位移動、員工離職、產品銷售等。
- MomentInteval：簡稱MIDetail，用淡紅色表示，主要表示MI的明細，常見的MIDetail有銷售明細、入庫明細、出庫明細等。
出差管理示例
根據四色原型進行聚合設計（四步曲）
第一步：識別模型
根據四色原型很容易識別出領域模型（見上圖）。
第二步：識別關聯
根據四色原型同樣很容易識別出領域模型之間的關系（見上圖）。
第三步：划分聚合
- MI和MIDetail是一個聚合，MI是聚合根。
- PPT是一個聚合，PPT是一個聚合根。如果Des只“描述”PPT，那么這個Des會作為一個值對象隸屬於屬於PPT所在的聚合。
- Des是一個聚合，Des是一個聚合根。前提你想“跟蹤”Des關聯的PPT。
- Role不屬於聚合，Role是一個帶狀態的領域服務，Role采用裝飾器模式裝飾PPT。
划分結果
第四步：精簡關聯
- 去掉MI和Role之間的關聯，改為倉儲查詢，根據需要讓MI關聯一個Role的快照（發生時刻Role的狀態）。將關聯改為倉儲查詢的理由是這樣更加靈活，一個請假人有1W個請假單，沒有必要設置這樣的關聯。讓MI關聯一個Role的快照的理由是MI很多情況要記錄下發生時刻Role的狀態，如：出差單要記錄下發生時刻請假人的組織信息，而不是現在的組織信息。
- PPT和DES之間的關聯可以根據自己的愛好酌情保留，我喜歡用倉儲查詢，這樣更靈活。
- 去掉PPT和Role之間的關聯，改為倉儲查詢。比如：用倉儲查出PPT，然后將這個PPT實例注入到Role中。
精簡結果
為什么銷售單和銷售單明細是一個聚合，而文章和評論不是一個聚合呢？
因為銷售單是MI，銷售單明細是MIDetail，因此他們是一個聚合；而文章是MI，評論也是MI，所以他們不是一個聚合。
備注
四色原型可以幫助我們做聚合設計，我相當於把聚合設計問題踢給四色原型分析了，本文還沒有詳細討論如何識別領域中的四色原型。當然了，聚合設計還有其他規律可循，后面慢慢討論吧。時間有限，后面我會用HappyFramework寫個Demo。
今天還沒有過多的談“職責分配”的問題，四色原型可以完美的補充DDD關於職責分配的各種模式，我會放到下一個主題討論。