Можем ли мы использовать REST + Event Sourcing + CQRS вместе
Я понимаю основы REST + Event Sourcing. Я никогда не работал над строгим RESTful API и ни в каком проекте Event Sourcing.
Может кто-нибудь объяснить, могут ли оба использоваться вместе?
Как и при получении событий, клиент отправляет события. Означает ли это, что на сервере существует одна коллекция событий, и все POST API будут в этой коллекции, чтобы добавлять в нее события?
Как клиент может обнаружить команды, которые он может отправить на сервер?
3 ответа
Может кто-нибудь объяснить, могут ли оба использоваться вместе?
Да. Клиент (браузер) просто делает то, что хочет, и сервер (http) может записывать эти действия как события.
Как и при получении событий, клиент отправляет события. Означает ли это, что на сервере существует одна коллекция событий, и все POST API будут в этой коллекции, чтобы добавлять в нее события?
Нет. Клиент может быть источником событий, но не должен знать, что представляет собой событие, чтобы предотвратить тесную связь между сервером и клиентом на основе этой коллекции событий. Event Sourcing должен быть инкапсулирован и скрыт от актера.
Как клиент может обнаружить команды, которые он может отправить на сервер?
В этом нет необходимости, если вам не нужно отправлять события из одной коллекции, как вы предлагали в предыдущем вопросе. Вы можете просто опубликовать REST API любым способом и скрыть источник событий от клиента / субъекта. Посмотрите на http://restdesc.org/.
REST - это метод доставки, он определяет интерфейс вашего приложения. Вы используете REST в основном с моделью немедленной согласованности, но она может поддерживать модель возможной согласованности, отвечая 202 принятым командами.
Источник событий - это общий механизм хранения данных. Вы обычно используете источник событий с моделью конечной согласованности наряду с управляемым доменом дизайном и разделением команд и запросов, но он может поддерживать модель немедленной согласованности, вероятно, посредством многофазной фиксации.
Они решают совершенно разные вещи в вашем приложении и совместимы друг с другом, поэтому вы можете использовать их вместе.
Как и при получении событий, клиент отправляет события. Означает ли это, что на сервере существует одна коллекция событий, и все POST API будут в этой коллекции, чтобы добавлять в нее события?
Вы совершенно не поняли концепцию. Вы можете сохранить последовательность событий в хранилище событий. Событие - это изменение состояния, поэтому, если вы сохраняете каждое изменение состояния вашего приложения и воспроизводите его в правильном порядке, вы можете воссоздать текущее состояние вашего приложения. Это очень хорошо, потому что вы можете перенести данные в другую базу данных, просто воспроизведя события и преобразовав их в запросы к базе данных. Вы можете сделать то же самое, чтобы создать кеш запросов, используя обычную базу данных. Таким образом, ваши клиенты могут читать этот кэш запросов вместо того, чтобы всегда воссоздавать текущее состояние с основания.
События обычно не создаются клиентом. В соответствии с дизайном, управляемым доменом, логика вашего домена создает события домена путем обработки команд.
Как клиент может обнаружить команды, которые он может отправить на сервер?
По REST клиенты используют ссылки для отправки запросов в службу REST. Служба REST может обрабатывать эти запросы и преобразовывать их в команды и запросы. Команды обрабатываются логикой домена и приводят к возникновению событий домена. Запросы преобразуются в запросы к базе данных, которые обращаются к кешам запросов.
Краткий ответ - да, мы можем.
Все вещи, которые вы перечисляете, я имею в виду REST, источник событий (ES) и CQRS, предназначены для разных целей. Так что я не вижу никаких проблем, чтобы собрать все это вместе.
Давайте посмотрим - REST - это способ создания API веб-службы, ES - инструмент для взаимодействия внутри домена, а CQRS - архитектура среднего уровня.
Что ж, в ES клиент (если мы говорим о веб-клиенте) не отправляет доменные события. Если вы имеете в виду другой ограниченный контекст, и этот ограниченный контекст является частью вашего домена, я думаю, что транспортировка событий должна решаться другим способом, служебной шиной или чем-то вроде этого было бы здорово. Если ограниченный контекст не является частью вашего домена, вы должны сообщить об этом через ACL и API, а не необработанные события домена.:)
Коротко о командах. Опять же, в CQRS команды живут внутри границ приложения. Внешние клиенты (веб-клиенты, api-клиенты) не должны иметь возможности напрямую отправлять команды приложения. Вы должны предоставить API (внутренний клиент), который позволял бы выполнять некоторые сценарии использования службы, а не отдельные и отдельные команды. В качестве собственного примера вы можете попробовать получить ответ на очень популярный вопрос SO - как проверить уникальность имени пользователя, когда мы используем CQRS?:)