Является ли CQRS хорошим подходом для реализации социального приложения в Google App Engine?

Мне кажется, что подход CQRS (Command and Query Responsibility Segregation) может быть подходящим для внедрения надежного и отзывчивого сервера социальных приложений в GAE, потому что:

  • CQRS не требует базы данных SQL (которую GAE не предоставляет)
  • Для этого требуется база данных, способная хранить сериализованные объекты, которые GAE действительно предоставляют
  • Он требует очередей событий, которые GAE также предоставляет
  • Он поддерживает неблокирующую, асинхронную, основанную на сообщениях архитектуру, которая аккуратно работает вокруг ограничений GAE для долгосрочных транзакций.
  • Он рекламируется как очень масштабируемый, что в конечном итоге объясняет, почему оптимисты выбирают GAE

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

Я думаю, что мои основные вопросы:

  • Сложный комплекс CQRS для ранних этапов нового приложения?
  • Есть ли какие-либо ловушки-мины, которые могли бы сделать их плохой, например, такие как GAE Datastore, возможно, не соответствовали требованиям CQRS?
  • Кто-нибудь может рекомендовать Axon или Jdon как особенно подходящий (или неподходящий) для GAE?
  • Какие еще вопросы я должен задать?

Ответы

Ответ 1

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

В CQRS с источником событий хранилище данных незначительно, потому что вам не требуется многого из вашего механизма хранения - NEventStore проект (написанный на С#) может легко поддерживать 40-50 различных типов хранилищ без особых трудностей.

Оба чистых Amazon Web Services и Google App Engine являются отличными платформами для приложения CQRS, потому что они направляют вас ко всем правильным выборам инфраструктуры - асинхронной, неблокирующей коммуникации с использованием обмена сообщениями.

Я никогда не слышал об Jdon, но Axon уже давно. Старайтесь не слишком сильно опираться на рамки. По мере углубления понимания CQRS это станет более очевидным - в основном это похоже на попытку избежать использования Hibernate везде в вашем коде. Вы должны использовать только Axon (или какой бы вы ни выбрали) именно там, где он должен использоваться, и не более.

Некоторые из лучших вопросов, которые вы можете задать, где искать помощь и какие ресурсы уже доступны, помогут вам понять, что такое CQRS. Существует множество хороших блогов и веб-сайтов, включая cqrsinfo.com, которые помогут вам начать работу. Кроме того, шестикратное видео Грега Янга является обязательным, если вы собираетесь начать с CQRS.