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