Как вы храните мутировавшее состояние, управляемое событиями программирование? - PullRequest
Новая
       42

Как вы храните мутировавшее состояние, управляемое событиями программирование?

0 голосов
/ 08 декабря 2018

У меня есть следующий случай, когда я чешу голову.У меня есть Агрегат, назовем его Reservation, и у меня есть событие.Некоторые события приведут к изменению состояния агрегата.Часть этого состояния является функциональной и, естественно, относится к совокупному, например, к «рассчитанному налогу».Часть состояния, которое я бы сказал, скорее техническая, чем функциональная, например, если сообщение отправляется в стороннюю систему, можно назвать его «isMessageSentToASystem».В базе данных у меня есть две таблицы: одна для совокупности, другая для события.Я вижу два варианта сохранения состояния:

1) Я могу сохранить только то, что изменилось в третьей таблице, связанной с событием.Таким образом, я эффективно получу журнал ревизий.Я не думаю, что это хорошо подходит для моего приложения, хотя.Это сохранит мой агрегат неизменным

2) Я приму, что мой агрегат является изменяемым, и я запишу в него все функционально важные состояния, такие как «selectedTax».Но тут возникает вопрос, что мне делать с техническим состоянием, таким как «isMessageSenttoSystemA», так как у меня возникает ощущение, что это состояние не относится к самому агрегату, а является побочным эффектом события.

Могу ли я создать третью таблицу и связать ее с событием, где я могу написать свое техническое состояние?Как мне назвать такую ​​таблицу?Мне действительно трудно найти правильное имя?

ОБНОВЛЕНИЕ: Я не уверен, станет ли это понятным из вопроса. Но меня больше всего интересует, как моделировать данные в базе данных.Я использую RDBMS.

UPDATE2: я не хочу реализовывать источник событий, и я думаю, что это не является обязательным условием для создания архитектуры, управляемой событиями.

Ответы [ 2 ]

0 голосов
/ 13 декабря 2018

Неизмененное состояние И мутирующие события принадлежат совокупности.

Я настоятельно рекомендую вам загрузить код Вона Вернона, он является автором книги «Реализация доменного управления (IDDD)».

Вот класс, который содержит ответы на ваши вопросы:

https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_common/src/main/java/com/saasovation/common/domain/model/EventSourcedRootEntity.java

Обратите внимание на логику здесь и связь с EventStore, есть список мутирующих событий, событий, которыеэффективно изменяют вашу сущность и указатель на неизмененную версию.Они используются в реализации хранилища событий, проверьте реализацию MySQL.

https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_common/src/main/java/com/saasovation/common/port/adapter/persistence/eventsourcing/mysql/MySQLJDBCEventStore.java

На стороне загрузки все события из хранилища событий загружаются и применяются к событию.исходная корневая сущность, но не сохраненная в списке изменяющихся событий.Таким образом, состояние вашей сущности восстанавливается до последней версии вашего журнала аудита, и любые изменения отслеживаются в памяти в этом списке, который записывается в базу данных при сохранении.

Что касается структуры событияхранить сам, это очень просто: 

CREATE TABLE `tbl_es_event_store` (
    `event_id` bigint(20) NOT NULL auto_increment,
    `event_body` varchar(65000) NOT NULL,
    `event_type` varchar(250) NOT NULL,
    `stream_name` varchar(250) NOT NULL,
    `stream_version` int(11) NOT NULL,
    KEY (`stream_name`),
    UNIQUE KEY (`stream_name`, `stream_version`),
    PRIMARY KEY (`event_id`)
) ENGINE=InnoDB;
0 голосов
/ 08 декабря 2018

isMessageSentToSystemA - сервис на стороне запроса, вы можете проверить это ограничение перед отправкой команды и изменением агрегата.Также вы можете использовать SAGA для выполнения распределенных транзакций и управления рабочим процессом вашего варианта использования

...