在Event Sourcing模式中，您是否有两个不同的类来读取和写入事件?

In the Event Sourcing pattern, do you have two different classes for reading and writing events?

本文关键字：两个 读取 入事件 模式 Sourcing Event 是否      更新时间：2023-10-16

是否应该将存储事件流中的与读取事件流中的分开实现?

例如，下面的抽象基类提供了一种持久化事件的方法，以便以后可以重播这些事件。

class event_store_t {
public:
    virtual void store(const event_t& event) = 0;
    virtual ~event_store_t() {}
};
用于测试的具体派生类的接口如下: 
class ostream_event_store_t : public event_store_t {
public:
    virtual void store(const event_t& event);
};

现在，当在以后的时间点重播事件时，是否应该有一个单独的类来读取事件?例如，抽象基类显示为:

class event_stream_t {
public:
    virtual boost::shared_ptr<event_t> read() = 0;
};

和具体的派生类显示为:

class istream_event_stream_t : public event_stream_t {
public:
    istream_event_stream_t(std::istream& input) : input_(input) {}
    virtual boost::shared_ptr<event_t> read() {
        // Read the event.
    }
};

事件流中的事件存储应该与事件流中的事件读取分开实现吗?

可能不是吗?

将你的load实现与store实现分开的主要动机是这样你就可以独立地交换实现。

如果这还没有发生在你身上，那么你是在预先加载成本到你的设计中，假设现在分离成本将比以后更有效，记住，在这个假设的"以后"，你将比现在更了解变化的需求。

这似乎不是个好主意。

也就是说，您可能已经注意到需要读功能的消费者并不总是需要写功能，反之亦然。因此，有一个读接口与写接口分开，用一个模块实现这两个接口是有意义的。

相关文章：