Apache Kafka Streams и Event Sourcing, CQRS и валидация

Question

У нас есть несколько устаревших приложений, в основном состоящих из GUI + сервисный уровень + RDMS. Со временем было добавлено несколько пакетов для синхронизации / передачи данных между различными базами данных и т. Д. Обычная архитектура спагетти:)

Мы находимся на пути к устранению этого беспорядка, и мы разрабатываем архитектуру на основе event sourcing и materialized views:

• Журнал событий на основе потоков Кафка и Кафка
• События передаются в приложения-потребители, которые используют / хранят данные так, как они хотят

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

В устаревших приложениях, когда пользователь обновляет данные в пользовательском интерфейсе, сервисный уровень проверяет (технические проверки и бизнес-проверки) перед сохранением нового состояния в базе данных. (Под technical checks я подразумеваю проверку типа полей, длины, существования внешних ключей и т. П. business checks, например, «если attr_A = xxx, тогда attr_B не может быть нулевым».)

Для новой архитектуры, даже если мы взяли на себя обязательство полагаться на шаблон event sourcing, я понял, что в настоящее время разрабатываю что-то, что больше похоже на решение CQRS + Event Sourcing:

Service layer > Kafka topic "Commands" > Validation > Kafka topic "Events" > Consuming apps

(с Service layer принадлежит приложению производителя.) В этом проекте важно иметь в виду, что «производящее приложение» также является «потребляющим приложением», и база данных производящего приложения будет обновляться только в конце цикла.

И я не уверен, что мы находимся в правильном направлении. Я предвижу 2 или 3 другой способ пойти дальше. Никто из них не удовлетворен на 100%:

1. Если вы продолжите эту опцию CQRS

Сохранение темы «команды»:

Service layer > Kafka topic "Commands" > Validation > Kafka topic "Events" > Consuming apps
<PRODUCING APP> <---------------------- STREAMING PLATFORM ----------------><.CONSUM APP.>

Я разработал фазу Validation для управления приложениями Kafka Streams. В этом случае было бы не слишком сложно обработать то, что я назвал ранее «техническими проверками». Но я действительно не уверен, что Streaming Platform является правильным местом для обработки бизнес-чеков.

2. Если вы продолжите использовать эту опцию CQRS, без проверки бизнеса

Сохранение темы "команды":

Service layer   >  Kafka topic "Commands" > Kafka topic "Events"   >  Consuming apps
<.PRODUCING APP.> <---------------- STREAMING PLATFORM ------------> <..CONSUM APP..>

Мы можем достичь точки, когда приложения могут генерировать недопустимые события, события, которые даже не могут быть сохранены в его собственной БД. (Например, приложение может нажать команду типа «Создать новый адрес», которая содержит код страны, которого нет в таблице «Страна».) Это похоже на парадокс: «событие» существует, это факт, но этот факт не принят его родителем.

3. Если мы используем Кафку для хранения темы «События», а не «Команды»:

Без «команд»:

Service layer   >  Kafka topic "Events"   >  Consuming apps

Здесь снова, как избежать создания приложениями для публикации недействительных событий.

Что бы вы предложили?

• Есть ли концепция, которую я пропустил в своем дизайне?
• Имеет ли смысл работать с CQRS?
• Должна ли "потоковая платформа" не выполнять проверку, доверять производящим приложениям и принимать все события в теме?
• Перед отправкой команд или событий, приложения должны проверять данные по данным, которыми они уже управляют?

С уважением,

Answer 1

Есть ли концепция, которую я пропустил в своем дизайне?

Есть другие вопросы по SO, касающиеся Kafka Streams и CQRS. Я бы порекомендовал посмотреть, является ли Kafka Streams правильным инструментом для обеспечения хранилища транзакционных событий.

Имеет ли смысл работать с CQRS?

Я не знаю, что CQRS будет волшебной пулей, чтобы убрать беспорядок в коде спагетти, который у вас сейчас есть. Существует кривая обучения, связанная с CQRS, включая выбор правильных границ домена и совокупности. Если в вашей команде нет никого, кто имеет опыт работы с CQRS, то путешествие может быть довольно сложным и может просто представить новый класс проблем, с которыми вам придется иметь дело. Лучше дьявола ты знаешь, как говорится.

Должна ли "потоковая платформа" не выполнять проверку, доверять производящим приложениям и принимать все события в теме?

Команды должны проверяться уровнем домена, и эта проверка может быть смоделирована в домене. Но вы должны также поддерживать некоторый уровень проверки при принятии пользовательского ввода. Если поле является обязательным, убедитесь, что оно не пустое, например, когда пользователь его предоставляет.

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

Перед отправкой команд или событий, приложения должны проверять данные по данным, которыми они уже управляют?

Обычно нет. Против чего будут проверять приложения? Если в очереди есть события, которые не были применены к вашему источнику данных во время проверки, вы можете неправильно отклонить команду или событие. В зависимости от ваших гарантий синхронизации, вам может потребоваться запросить уровень вашего домена, чтобы принять решение о том, какие команды следует выполнить дальше. Как правило, ваш Агрегат или Сага будут знать достаточно, чтобы принимать решения по мере необходимости.

Потратьте некоторое время на чтение http://www.cqrs.nu. Это помогло мне установить базовое понимание CQRS и Event Sourcing, прежде чем думать о фактической реализации.

Приветствия и удачи в вашем увлекательном путешествии.