Создание микросервисов через управляемую событиями архитектуру, часть 8

В этой статье я расскажу о внедрении Event-Sourcing вашего приложения. Этот уровень окружает домен и реализует варианты использования (бизнес-правила для конкретного приложения). Он управляет потоком данных и использует модель предметной области и инфраструктуры и не зависит от базы данных, пользовательского интерфейса или специальных сред.

Вам также может понравиться:
Создание микросервисов на основе событийно-управляемой архитектуры, часть 7

Для нашей системы обработки событий я возьму все незафиксированные события из агрегата и вызову функцию хранилища, которая будет отвечать за сохранение событий в хранилище событий. Поэтому я буду вызывать функцию AppendAsync (EventStore @event) в IEventStoreRepository .

Поскольку я еще не внедрил обновления, я не буду заботиться о агрегатной версии (у меня есть один метод post, который создает речь, поэтому агрегатная версия всегда будет равна нулю).
Когда я буду внедрять обновления, я позабочусь о агрегатной версии на уровне приложений и презентации.

Интерфейсы Event-Sourcing

Я могу определить два интерфейса IEventSourcingSubscriber и IEventSourcingHandler , вы можете использовать другое соглашение об именах, но пока я оставляю их как есть.

Subscribe — это функция, которая получает все незафиксированные события из агрегата и для каждого события вызывает функцию
Handle, которая принимает событие и текущую версию агрегата в качестве входных данных.

Дескриптор — это функция, которая сериализует событие в строку и вызывает AppendAsync (EventStore @event) из IEventStoreRepository.

Внедрение Event-Sourcing

Внедрение подписки на Event-Sourcing

Итак, первый тест должен быть следующим: подписка без незафиксированных событий не должна вызывать дескриптор

У меня нет незафиксированных событий, я ничего не буду делать. Тогда раздел Assert будет выглядеть так:

mockEventSourcingHandler. Verify (m => m. Handle (It.IsAny <Event> (), It.IsAny <long> ()), Times.Never , «Handle не должен вызываться»);

Тестовый пример 1: подписка без незафиксированных событий не должна вызывать дескриптор

Здесь я закончу реализацию своей функции

Тестовый пример 2: подписка с незафиксированными событиями должна обрабатывать вызов только один раз

mockEventSourcingHandler. Verify (m => m. Handle (It.IsAny <Event> (), It.IsAny <long> ()), Times.Once , «Handle должен вызываться только один раз»).

В разделе Assert я могу убедиться, что функция Handle вызывается только один раз.

Окончательная реализация EventSourcingSubscriber должна выглядеть следующим образом:

Я вызываю функцию-обработчик для каждого события.

Реализация обработчика событий

Тестовый пример 3: обработка с нулевыми событиями должна вызывать Eventnullexception

Я высмеиваю некоторые зависимости и проверяю, что если событие нулевое, то дескриптор должен вызвать исключение.

Вот реализация теста.

Здесь я проверяю, что если событие не является нулевым, то Handle должен вызвать AppendAsync.

Вот реализация теста. Вы можете заметить, что я использую интерфейс IEventSerializer для сериализации события в строку JSON, эта строка JSON будет полезной нагрузкой потока событий.

Обновление RegisterSpeechUseCase

Затем обновите RegisterSpeechUseCase и вызовите функцию подписки : await _domainEventSubscriber.Subscribe (речь);

Обновить презентацию

Откройте файл Startup.cs и настройте некоторые внедрения зависимостей.

Откройте appsettings.Development.json и обновите ConnectionStrings, чтобы использовать соответствующий сервер базы данных, имя базы данных и учетные данные.

Скрипты для создания базы данных находятся в проекте LogCorner.EduSync.Speech.Database.