package domain.event;

import java.util.Date;
import java.util.UUID;

/**
 * @Description:
 * @Author: zhangwenbo
 * @Since: 2019/3/6
 */
public class DomainEvent {

    /**
     * 領域事件還包含了唯一ID，
     * 但是該ID並不是實體（Entity）層面的ID概念，
     * 而是主要用於事件追溯和日誌。
     * 如果是數據庫存儲，該字段通常爲唯一索引。
     */
    private final String id;

    /**
     * 創建時間用於追溯，另一方面不管使用了
     * 哪種事件存儲都有可能遇到事件延遲，
     * 我們通過創建時間能夠確保其發生順序。
     */
    private final Date occurredOn;

    public DomainEvent() {
        this.id = String.valueOf(UUID.randomUUID());
        this.occurredOn = new Date();
    }
}

（滑動可查看）

在創建領域事件時，需要注意2點：

• 領域事件本身應該是不變的(Immutable)；

• 領域事件應該攜帶與事件發生時相關的上下文數據信息，但是並不是整個聚合根的狀態數據。例如，在創建訂單時可以攜帶訂單的基本信息，而對於用戶更新訂單收貨地址事件AddressUpdatedEvent事件，只需要包含訂單、用戶以及新的地址等信息即可。

public class AddressUpdatedEvent extends DomainEvent {
    //通過userId+orderId來校驗訂單的合法性；
    private String userId; 
    private String orderId;
    //新的地址
    private Address address;
    //略去具體業務邏輯
}

（滑動可查看）

事件的不可變性與可追溯性都決定了其必須要持久化的原則，我們來看看常見的幾種方案。

3.1單獨的EventStore

有的業務場景中會創建一個單獨的事件存儲中心，可能是Mysql、Redis、Mongo、甚至文件存儲等。這裏以Mysql舉例，business_code、event_code用來區分不同業務的不同事件，具體的命名規則可以根據實際需要。

這裏需要注意該數據源與業務數據源不一致的場景，我們要確保當業務數據更新以後事件能夠準確無誤的記錄下來，實踐中儘量避免使用分佈式事務，或者儘量避免其跨庫的場景，否則你就得想想如何補償了。千萬要避免，用戶更新了收貨地址，但是AddressUpdatedEvent事件保存失敗。

總的原則就是對分佈式事務Say No，無論如何，我相信方法總比問題多，在實踐中我們總可以想到解決方案，區別在於該方案是否簡潔、是否做到了解耦。

# 考慮是否需要分表，事件存儲建議邏輯簡單
CREATE TABLE `event_store` (
  `event_id` int(11) NOT NULL auto increment,
  `event_code` varchar(32) NOT NULL,
  `event_name` varchar(64) NOT NULL,
  `event_body` varchar(4096) NOT NULL,
  `occurred_on` datetime NOT NULL，
  `business_code` varchar(128) NOT NULL,
  UNIQUE KEY (`event id`)
) ENGINE=InnoDB COMMENT '事件存儲表';

（滑動可查看）

3.2 與業務數據一起存儲

在分佈式架構中，每個模塊都做的相對比較小，準確的說是“自治”。如果當前業務數據量較小，可以將事件與業務數據一起存儲，用相關標識區分是真實的業務數據還是事件記錄；或者在當前業務數據庫中建立該業務自己的事件存儲，但是要考慮到事件存儲的量級必然大於真實的業務數據，考慮是否需要分表。

這種方案的優勢：數據自治；避免分佈式事務；不需要額外的事件存儲中心。當然其劣勢就是不能複用。

/*
* 一個關於比賽的充血模型例子
* 貧血模型會構造一個MatchService，我們這裏通過模型來觸發相應的事件
* 本例中略去了具體的業務細節
*/
public class Match {
    public void start() {
        //構造Event....
        MatchEvent matchStartedEvent = new MatchStartedEvent();
        //略去具體業務邏輯
        DefaultDomainEventBus.publish(matchStartedEvent);
    }

    public void finish() {
        //構造Event....
        MatchEvent matchFinishedEvent = new MatchFinishedEvent();
        //略去具體業務邏輯
        DefaultDomainEventBus.publish(matchFinishedEvent);
    }

    //略去Match對象基本屬性
}

（滑動可查看）

package domain;

import domain.event.DomainEvent;
import domain.handler.event.DomainEventHandler;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

/**
 * @Description: 事件註冊邏輯
 * @Author: zhangwenbo
 * @Since: 2019/3/6
 */

public class DomainRegistry {

    private Map<String, List<DomainEventHandler>> handlerMap =
        new HashMap<String, List<DomainEventHandler>>();

    private static DomainRegistry instance;

    private DomainRegistry() {
    }

    public static DomainRegistry getInstance() {
        if (instance == null) {
            instance = new DomainRegistry();
        }
        return instance;
    }

    public Map<String, List<DomainEventHandler>> getHandlerMap() {
        return handlerMap;
    }

    public List<DomainEventHandler> find(String name) {
        if (name == null) {
            return null;
        }
        return handlerMap.get(name);
    }

    //事件註冊與維護，register分多少個場景根據業務拆分，
    //這裏是業務流的核心。如果多個事件需要維護前後依賴關係，
    //可以維護一個priority邏輯
    public void register(Class<? extends DomainEvent> domainEvent,
                         DomainEventHandler handler) {
        if (domainEvent == null) {
            return;
        }
        if (handlerMap.get(domainEvent.getName()) == null) {
            handlerMap.put(domainEvent.getName(), new ArrayList<DomainEventHandler>());
        }
        handlerMap.get(domainEvent.getName()).add(handler);
        //按照優先級進行事件處理器排序
        。。。
    }
}

（滑動可查看）

文件上傳完畢事件的例子。

package domain.handler.event;

import domain.DomainRegistry;
import domain.StateDispatcher;
import domain.entity.meta.MetaActionEnums;
import domain.event.DomainEvent;
import domain.event.MetaEvent;
import domain.repository.meta.MetaRepository;
import org.springframework.stereotype.Component;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;

/**
 * @Description:一個事件操作的處理器
 * 我們混合使用了Saga的兩種模式，外層事件交互；
 * 對於單個複雜的事件內部採取狀態流轉實現。
 * @Author: zhangwenbo
 * @Since: 2019/3/6
 */

@Component
public class MetaConfirmUploadedHandler implements DomainEventHandler {

    @Resource
    private MetaRepository metaRepository;

    public void handle(DomainEvent event) {
        //1.我們在當前的上下文中定義個ThreadLocal變量
        //用於存放事件影響的聚合根信息(線程共享)

        //2.當然如果有需要額外的信息，可以基於event所
        //攜帶的信息構造Specification從repository獲取
        // 代碼示例
        // metaRepository.queryBySpecification(SpecificationFactory.build(event));

        DomainEvent domainEvent = metaRepository.load();

        //此處是我們的邏輯
        。。。。

        //對於單個操作比較複雜的，可以使用狀態流轉進一步拆分
        domainEvent.setStatus(nextState);
        //在事件觸發之後，仍需要一個狀態跟蹤器來解決大事務問題
        //Saga編排式
        StateDispatcher.dispatch();
    }

    @PostConstruct
    public void autoRegister() {
        //此處可以更加細分，註冊在哪一類場景中，這也是事件驅動的強大、靈活之處。
        //避免了if...else判斷。我們可以有這樣的意識，一旦你的邏輯裏面充斥了大量
        //switch、if的時候來看看自己註冊的場景是否可以繼續細分
        DomainRegistry.getInstance().register(MetaEvent.class, this);
    }

    public String getAction() {
        return MetaActionEnums.CONFIRM_UPLOADED.name();
    }

    //適用於前後依賴的事件，通過優先級指定執行順序
    public Integer getPriority() {
        return PriorityEnums.FIRST.getValue();
    }
}

（滑動可查看）

事件總線邏輯

package domain;

import domain.event.DomainEvent;
import domain.handler.event.DomainEventHandler;
import java.util.List;

/**
 * @Description:
 * @Author: zhangwenbo
 * @Since: 2019/3/6
 */

public class DefaultDomainEventBus {

    public static void publish(DomainEvent event, String action,
                               EventCallback callback) {

        List<DomainEventHandler> handlers = DomainRegistry.getInstance().
            find(event.getClass().getName());
        handlers.stream().forEach(handler -> {
            if (action != null && action.equals(handler.getAction())) {
                Exception e = null;
                boolean result = true;
                try {
                    handler.handle(event);
                } catch (Exception ex) {
                    e = ex;
                    result = false;
                    //自定義異常處理
                    。。。
                } finally {
                    //write into event store
                    saveEvent(event);
                }

                //根據實際業務處理回調場景，DefaultEventCallback可以返回
                if (callback != null) {
                    callback.callback(event, action, result, e);       
                }
            }
        });
    }
}

（滑動可查看）

不過我們還是要認識到在其適合的場景中，六邊形架構以及DDD戰術將加速我們的領域建模過程，也迫使我們從嚴格的通用語言角度來解釋一個領域，而不是一個個需求。任何更強調核心域而不是技術實現的方式都可以增加業務價值，並使我們獲得更大的競爭優勢。

附：參考文獻

1. Pattern: Saga

2. 分佈式事務：Saga模式

3. 書籍：《微服務架構設計模式》

• 領域驅動設計(DDD)實踐之路(一)

• vivo 大規模特徵存儲實踐

• 分佈式定時任務調度框架實踐

• 揭祕 vivo 如何打造千萬級 DAU 活動中臺 - 啓航篇

vivo移動互聯網是基於vivo 智能手機所建立的完整移動互聯網生態圈，圍繞vivo大數據運營，打造包括應用、遊戲、資訊、品牌、電商、內容、金融、搜索的全方位服務生態，滿足海量用戶的多樣化需求。