用“資料與演算法”解釋DDD“上下文和聚合”

• “資料”=“上下文”
• “演算法”= “聚合”

資料=上下文
首先，資料本身是上下文的一種體現，如果你熟悉寫作文，那麼作文要求你說明來龍去脈，上下文背景需要交待清楚，那麼這些文字本身就是一種資料，一個領域中大量相關資料堆積在一起就能說明某種場景的上下文背景。
當然，這裡上下文是有限制的、有邊界的，也就是說：資料不是無限多，資料也是有限的，有一定意義的，比如圍繞購物車發生的資料是發生在購物的上下文中；而下訂單上下文中發生的資料則是圍繞即將生成的訂單進行的，比如需要填入收貨地址，選擇優惠碼或湊單等等。

理解以上概念以後，事件建模或事件溯源EventSourcing概念就容易理解：
在上下文中發生的資料是一種“事件”。

也就是說：事件也是一種資料，只不過是發生的動作或活動的資料，把動詞“事件”對映成名詞“資料”，事件建模就是追蹤一個需求流程中這些動作或活動，然後定義起止範圍，也就是作用域，這段作用域就類似有界上下文BC，例如購物車上下文的起止作用域；下單上下文的起止作用域範圍，這樣我們就得到兩個上下文：購物車上下文和下單上下文。

那麼，關鍵就是界定上下文的開始與最後的作用域範圍，也就是起點和終點，如果把事件資料看成是“點”，那麼“點”串起來的就是“線”或“流stream”或“流程”，這就是上下文的作用域範圍，就是有界的上下文BC。
一段線總是有兩個端點，正如染色體兩端有兩個端粒影響人的壽命一樣，上下文界限對整體DDD設計也非常重要。

如果你一開始無法界定上下文這段範圍，或者可能隨著時間邊界會動態變化，那麼採取事件溯源先把一段或可能包含幾段線的資料“點”儲存起來，以後再從中發現演算法或聚合。

演算法=聚合
演算法本身代表一種聚合的意思，例如：X+Y 是加法，是將兩個元素相加在一起的演算法，那麼，這裡演算法本身體現了高凝聚的特點，如果說有界上下文BC是一種截斷耦合實現鬆耦合的方法，那麼演算法或聚合是實現高凝聚的方式。

羅伯-派克的5條程式設計規則：資料高於演算法：

資料占主導地位。如果你選擇了正確的資料結構並很好地組織了事情，演算法幾乎總是不言而喻的。資料結構（而不是演算法）才是程式設計的核心。

也就是說，當你界定好上下文資料以後，演算法會自然湧現emerge，演算法取決於你希望從這段上下文資料獲得什麼樣的洞察力和預見性，比如你想按照某個欄位合併或排序，那麼使用簡單SQL語句就可以實現，一條SQL語句本身就是一個聚合，否則怎麼會成為“語句呢”？這裡我們又碰到程式設計中的“作用域 vs. 語句”，

作用域=上下文；語句=聚合。

總結
看來處處都存在“上下文 vs. 聚合”，只要你多一個心眼，從這個新視角再重新看世界，你會發現世界果然是由這兩種元素組成，正所謂“陰與陽”一樣，上下文是藏在暗處的“陰”，而聚合是聚光燈下的“陽”。

原來二分法不只是“物質 vs. 意識”這樣的二分方式，還有“上下文 vs. 聚合”、“資料 vs. 演算法”、“作用域 vs . 語句”、“陰 vs. 陽”、“隱性 vs. 顯性”、“有效期 vs. 產品”、“劑量 vs. 藥品”等二分方式，這些方式是不是更實用？更具有可操作性？而且會糾正我們的認知偏見呢？