點贊，在互聯網中是壹個比較簡單的操作。用戶看到自己喜歡的信息，點擊“贊”按鈕，點亮“贊”操作，再次點擊，取消之前的“贊”操作。是不是很 easy？
但，壹個明星微博的點贊數可能高達幾十萬，甚至上百萬。壹個熱點新聞，可能有數千、數萬、甚至數十萬用戶同時點贊，如何處理這些極端情況呢？
如果要構建壹套通用點贊系統，首先需要對系統所涉及角色、主功能進行梳理。
這兩個角色，本質上是對其他對象的壹種引用。從領域設計角度，應該是對其他限界上下文中聚合的引用。兩個角色，本身沒有唯壹標識，並根據屬性確定其相等性。因此，符合值對象建模規範，應該作為值對象處理。
通常情況下，點贊發起者對應系統的用戶（有的系統會有多個用戶系統）。但，點贊的目標對象可能會有很多，如新聞、評論、帖子等等。
系統角色如下：
點贊發起者 Owner，可以選擇壹個點贊對象 Target 進行點擊操作。當顯示目標對象 Target 時，需要判斷該 Target 是否已經點過贊。
對於點贊對象 Target，只有壹個應用場景，就是在顯示時，獲取總的點贊數量。
詳細用例如下：
Like 可以接收點擊操作，並更新內部狀態。同壹個點贊發起者對同壹個點贊目標進行“贊”和“取消”操作時，針對的應該是同壹個 “Like” 實例，需要唯壹標識對操作進行跟蹤。綜上分析 “Like” 是壹個實體。
行為建模
分析下 Like 的業務行為，Like 對外操作只提供壹個 click 方法，當觸發 click 操作時，Like 在 Submitted 和 Cancelled 之間進行切換。當 Like 狀態發生變化時，需要發布對應的內部事件。
Like 所涉及的業務方法如下：
為了避免 Like 的臃腫，我們將 Like 的狀態進行單獨建模。構建壹個單獨的值對象，並將狀態相關的操作下推到該值對象中。我們稱為 LikeStatus 。
屬性建模
Like 所關聯的對象，包括 Target、Owner 和 LikeStatus，並且三者都是值對象。
創建方式建模
Like 的創建方式比較簡單，沒有太復雜的業務邏輯，因此，采用靜態方法對其進行創建。
Like 是壹個比較簡單的聚合，具體結構如下：
贊功能所涉及的對象見下表。
日誌，本身不屬於業務功能，但對用戶行為分析非常重要，我們應該將用戶的所有操作保存下來。我們稱這些過程數據為 LikeLogger。
日誌主要用於記錄誰（Owner）對什麽（Target）進行哪個操作（Action），在創建後就不在改變。基本符合值對象建模條件，但，我們如何對其進行持久化呢？
壹般情況下，值對象的持久化依賴於包含它的實體，值對象會隨著實體的持久化而持久化。但，Logger 是個整體概念，本身不屬於任何實體。在這種情況下，我們可以將其建模成壹個不變實體，壹來借助實體進行持久化，二來避免對實體的修改。
LikeLogger 為不變實體，內部所包含的屬性，不允許修改。
屬性建模
LikeLogger 所包含屬性如下：
創建方式建模
LikeLogger 支持 Like 和 Cancel 兩種類型的日誌，可以根據 ActionType 構建靜態方法，以完成各自的創建。
LikeLogger 所涉及對象包括：
從單壹職責原則角度，Like 承載了過多的責任，將統計功能強加到服務於業務的 Like 也非常不合適。因此，我們對計數功能進行獨立的業務建模。 我們稱為 TargetCount。
TargetCount 需要根據點贊和取消點贊對計數進行增減操作。對於同壹個 Target，需要持續跟蹤其數量變化。可見，TargetCount 是壹個實體。
行為建模
TargetCount 的操作，主要有 incr 和 decr 兩個業務操作。在進行 count 更新時，存在壹個業務規則，及 count 不能小於零。
屬性建模
TargetCount 的屬性包括：
創建方式建模
TargetCount 的創建方式比較簡單，因此，采用靜態方法對其進行創建。
計數功能所涉及對象包括：
這設計架構前，有幾個非功能性需求需要考慮。
對於寫操作優化，常見的策略包括：
對於壹致性要求高的業務場景（比如支付），數據散列是唯壹解決方案；對於壹致性要求不高的業務場景（比如咱們的點贊系統），隊列方案是最佳解決方案。
在此，我們使用隊列方案來應對點擊行為的高並發。即用戶提交點擊請求並不會直接調用業務方法，而是將請求放入消息隊列；後臺消費線程從消息隊列中獲取請求，並調用業務方法執行業務邏輯。
對讀操作的優化，主要是使用緩存進行訪問加速。我們使用 Redis 來加速訪問。
具體的操作如下：
系統的操作入口只有 Like 聚合，當 Like 發生變化時，Logger 和 Count 都需要跟著聯動起來。Like 與 Count、Logger 具有很強的因果關系，這也是領域事件建模的重要信號。
我們可以基於內存總線和內部事件，通過訂閱 Like 相關事件在內存中完成與 Logger、Count 的業務同步；也可以使用專用消息隊列和外部事件，完成多個系統間的數據同步。
Like 在執行完業務操作後，將內部領域事件直接發布到內存總線（EventBus），Exporter 組件從內存總線中獲取領域事件，將其轉換為外部事件，並發送到消息隊列中。Consumer 組件負責從消息隊列中獲取事件，調用 Logger、Count 相關業務接口以完成業務操作。
綜上分析，我們的最終架構如下：