Есть ли в шаблоне Event Sourcing два разных класса для чтения и записи событий?
Если хранения событий в потоке событий осуществляется отдельно от чтение событий в потоке событий?
Например, следующий абстрактный базовый класс предоставляет средства для сохранения событий, чтобы они могли быть воспроизведены позже.
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.
}
};
Решение
Должно ли хранение событий в потоке событий осуществляться отдельно от чтения событий в потоке событий?
Возможно нет?
Основная мотивация отделить реализацию загрузки от реализации магазина — вы можете менять реализации независимо друг от друга.
Если это еще не произошло с вами, тогда вы загружаете в свой проект издержки, исходя из того, что разделение затрат сейчас будет более эффективным, чем последующее, учитывая, что в этом гипотетическом «позже» Вы будете знать о требованиях к изменениям больше, чем сейчас.
Это не похоже на хорошую ставку.
Тем не менее, вы, возможно, заметили, что потребителям, которым нужны возможности чтения, не всегда нужны возможности записи, или наоборот. Так что может иметь смысл прочитать интерфейс это отдельный от интерфейса записи, с одним модулем, который реализует оба.
Другие решения