背景：现在微服务大行其道，虽然微服务开山鼻祖是不建议在微服务下做分布式事务，领域驱动设计早已阐明，具有强一致性要求的一组业务概念，属于同一个聚合，不建议拆到不同服务中，从而尽可能避免分布式强事务一致性的处理。但是不可避免我们没有真的按照DDD领域驱动设计，那么微服务如何保持事务一致性呢？

我们这里采用的EventStore的方式，有基于memory、jpa、jdbc等方式，我今天采用了MapDB framework的方式，MapDB提供多种多样方式的数据结构有link、set、map、queue等。

EventMessage

public interface Message<T> extends Serializable {
 
    String getIdentifier();
 
    MetaData getMetaData();
 
    T getPayload();
 
    Class<T> getPayloadType();
 
    Message<T> withMetaData(Map<String, ?> metaData);
 
    Message<T> andMetaData(Map<String, ?> metaData);
}

 MapDB eventStore

/**
 * Created by Young on 2017/4/11.
 */
public class MapDBEventStorageEngine implements EventStorageEngine {
    private final DB db = DBMaker.memoryDB().make();
    private static final String ORDER_LINK_LIST = "ORDER_LINK_LIST";
    private final Lock lock = new ReentrantLock();
    private final Condition dataAvailableCondition = lock.newCondition();
 
    @Override
    public void appendEvents(List<? extends EventMessage<?>> events) {
 
        lock.lock();
        try {
            IndexTreeList<Object> hs = db.indexTreeList(ORDER_LINK_LIST).createOrOpen();
            hs.addAll(events);
        } finally {
            lock.unlock();
        }
    }
 
    @Override
    public void storeSnapshot(DomainEventMessage<?> snapshot) {
 
    }
 
    @Override
    public Stream<? extends TrackedEventMessage<?>> readEvents(TrackingToken trackingToken, boolean mayBlock) {
        return null;
    }
 
    @Override
    public DomainEventStream readEvents(String aggregateIdentifier, long firstSequenceNumber) {
        return null;
    }
 
    @Override
    public Optional<DomainEventMessage<?>> readSnapshot(String aggregateIdentifier) {
        return null;
    }
}