Опыт работы с Axon Framework

Ответ 1

Структура в значительной степени зависит от eventourcing, что означает, что все изменения состояния > записываются в хранилище данных как события. "

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

Это лучше с event-sourcing.

Итак, у вас есть историческая ссылка на все ваши данные. Это приятно, но меняет ваш домен после того, как вы ушли в производство, очень сложное предложение, особенно если вы продали > клиенту в системе "сильную аудитоспособность" "

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

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

Это не связано с каркасом, а с используемым архитектурным шаблоном (CQRS). И жаль упоминать об этом, но наличие одного денормализатора/представления - хорошая идея, поскольку он остается простым объектом.

Таким образом, обслуживание легко, потому что запрос SQL/вставка также легко. Таким образом, этот аргумент не очень силен. Как насчет представления, которое использует модель 1000 таблиц с внутренними объединениями везде и сложные SQL-запросы?

Опять же, CQRS помогает, потому что в основном данные представления представляют собой только SELECT * из таблицы, которые соответствуют представлению.

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

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

Воспроизведение может иметь побочные эффекты, поэтому разработчики боятся делать это

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

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

Хорошо, если вы неправильно поняли и неправильно поняли архитектуру, концепцию и т.д., тогда я согласен с вами. Но, возможно, проблема здесь не в структуре.

Должен ли храниться дельта? абсолютные значения? если вы не будете следить за своими разработчиками, вы обязательно закончите с обоими, и вы будете f *** ed

Я могу сказать, что для каждой системы я бы сказал, что она не связана непосредственно с самой картой. Это похоже на то, что "Java - это дерьмо, потому что вы можете испортить все, если кто-то кодирует плохую реализацию hashCode и equals methods".

И для последней части вашего комментария я уже видел образцы, подобные helloWorld, с фреймворком Spring. Конечно, это совершенно бесполезно на простом примере.

Будьте осторожны в своем комментарии, чтобы сделать разницу между концепцией (CQRS + EventSourcing) и структурой. Сделайте разницу пожалуйста.

Ответ 2

Поскольку вы заявили, что хотите использовать CQRS для своего проекта (и я предполагаю, что JVM - ваша целевая платформа), я думаю, что Axon Framework - отличный выбор.

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

Поскольку я использую EventSourcing, тестовые приборы очень упростили запись BDD-стиля "заданные, когда, а затем" тесты. Это позволяет обрабатывать агрегат как черный ящик и концентрироваться на проверке того, что правильный набор событий выйдет, когда вы введете определенную команду.

О ловушках: перед прыжком, убедитесь, что

• Что вы поняли понятия CQRS.
• Составьте список (бумага, доска и т.д.) всех ваших агрегатов, обработчики команд, обработчики событий, саги, команды и события. Это трудная часть построения вашей системы, выяснения того, что она должна делать и как. После этого справочное руководство должно показать вам, как подключить все это вместе с Axon.

Некоторые неконкретные точки Axon:

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

Возможность создания нового компонента отчетности через год после запуска проекта и мгновенного получения отчетов о данных с момента запуска проекта и последующего использования является удивительной.

Ответ 3

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

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

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

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

Мы начали разработку с AxonFramework версии 1.0 и перешли к версии 1.4 по мере выпуска более новых версий.

Наш опыт работы с CQRS и реализация, представленная AxonFramework, были абсолютно положительными.

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

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

Наш выбор заключался в том, чтобы быть консервативным в модели записи, поэтому мы предпочли сохранение на основе JPA вместо того, чтобы его использовали.

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

В любом случае мы разработали модель записи, поскольку мы применяли источники событий, поэтому мы заботимся об изменении состояния агрегатов исключительно через события. Когда клиент попросил функцию клонирования очень сложного агрегата, это было просто переигровка исходных событий (с переводом uuid) на совершенно новый экземпляр - в этом случае нижняя сторона была событием upcasting (но эта функциональность была значительно улучшилась в ближайшей версии 2.0).

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

Как и любой другой человеческий продукт, AxonFramework не был иммунитет к ошибкам, но, к удивлению, для такого молодого и нишевого проекта они были немногочисленными, а не критичными и быстро решались новыми выпусками.

Типичная и немедленная поддержка, предоставленная автором в списке рассылки, является еще одной неоценимой особенностью и очень помогла мне, когда у меня были проблемы.

Приложение было выпущено в производство год назад и в настоящее время поддерживается и находится в активной разработке новых функций.

Клиент удовлетворен и просит большего.

Когда использовать AxonFramework - это больше вопрос использования CQRS. Для ответа стоит вернуться к официальной документации: http://www.axonframework.org/docs/1.4/introduction.html#d4e51

В нашем случае окончательно оно того стоило.

Ответ 4

ОП специально спрашивает о подводных камнях, связанных с Axon Framework, а не CQRS. Это затрудняет ответ на вопрос, так как Аксон начинал как довольно верная реализация знаменитой книги Эрика Эванса Eric Evans

.Основным преимуществом является то, что он делает именно то, что говорит на жестяной коробке: он обрабатывает для вас сложные части дизайна на основе CQRS: агрегаты, саги, источники событий, обработчики команд, обработчики событий, согласованность BASE и т.д. Когда вы следуете лучшим практики, вы в конечном итоге с очень отзывчивым и горизонтально масштабируемым приложением. Если вы используете его с источником событий, ваши данные полностью подлежат аудиту, и, по крайней мере, теоретически, вы можете определить состояние вашего приложения в любой данный момент времени. Инструменты для этого не предусмотрены; вам придется свернуть свой собственный.

Основной разработчик фреймворка очень доступен и чрезвычайно хорошо осведомлен о высокой производительности и масштабируемости вычислений в Java. Он имеет тенденцию отвечать на каждый вопрос в списке рассылки в течение нескольких часов. Это является как преимуществом, так и главной ошибкой: в настоящее время (начало 2014 года) Axon Framework сильно зависит от одного человека. Остальные подводные камни, о которых я хотел бы упомянуть, скорее всего, являются результатом события Sourcing, чем CQRS или Axon (по состоянию на 2018 г. фреймворк поддерживается компанией Axoniq)

Проектируйте свою модель данных очень тщательно заранее. Несмотря на то, что это легко добавить, внести фундаментальные изменения в вашу модель данных может быть очень сложно. Если вы совершите фундаментальную ошибку в модели данных, ваше приложение может работать неэффективно или даже вообще не работать. Например, если вы выберете модель данных в форме дерева с одним долгоживущим корнем агрегата наверху, этот агрегат может стать очень большим, так как со временем накапливается все больше и больше событий, и может потребоваться много времени для загрузки и хранения. Я не знаю, что произойдет, если это будет продолжаться до тех пор, пока экземпляр агрегата больше не поместится в ОЗУ, но я думаю, что это может быть плохо. Не делай так.

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

Исправление ошибок в данных может быть более сложным, чем при "традиционном" дизайне. Вместо простого оператора SQL вам часто нужно будет создать команду для изменения состояния вашего приложения. Если ошибка в ваших данных была вызвана ошибочным обработчиком событий, вы обычно можете просто исправить ошибку, очистить моментальные снимки и позволить воспроизвести события для агрегата. Если из-за вашей ошибки были применены ложные события, я могу решить гораздо больше проблем. Неисправные события останутся в хранилище событий, и вам, возможно, придется применить некоторые новые, чтобы восстановить ваши данные в правильном состоянии, или изменить код, чтобы игнорировать или исправить их поведение.

Ответ 5

В настоящее время я работаю над платформой онлайн-казино, которая запускает наш бренд Casumo этим летом. Домен и платформа построены с использованием Axon Framework, и до сих пор он нам очень помог.

Было сохранено много времени, не имея необходимости создавать всю инфраструктуру, необходимую для обработки команд, маршрутизации событий, поиска источников данных, создания снимков и т.д., и API-интерфейсы действительно приятно работать. Единственная ошибка, которую мы обнаружили в рамках до сих пор, была зафиксирована в релизе 12 часов спустя, и Allard всегда быстр, чтобы предлагать новые функции и обсуждать способы использования инфраструктуры для удовлетворения ваших потребностей.

Ответ 6

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

Структура в значительной степени зависит от eventourcing, что означает, что все изменения состояния записываются в хранилище данных как события. Таким образом, у вас есть историческая ссылка на все ваши данные. Это приятно, но меняет ваш домен после того, как вы начали производство очень сложное предложение, особенно если вы продали заказчику систему "сильной аудитоспособности"

У вас не могут быть операторы, которые делают ad-hoc изменения в базе данных

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

Если вы каким-то образом допустили ошибку в одном из обработчиков событий, единственным вариантом является "повторить" журнал событий, который в зависимости от размера ваших данных может занять очень много времени. Инструментарий для этого, однако, не существует. Воспроизведение может иметь побочные эффекты, поэтому разработчики боятся делать это

очень легко заставить разработчиков испортить эту инфраструктуру. если они не сохраняют изменения в объектах домена в событиях, в следующий раз, когда вы будете воспроизводить свои события, вы будете удивлены. Должны ли вы хранить дельту? абсолютные значения? если вы не будете следить за своими разработчиками, вы обязательно закончите с ними, и вы будете f *** ed

Практически нет принятия этой структуры, поэтому поиск по поисковым запросам не принесет вам никакой пользы

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

Ознакомьтесь с некоторыми примерами . Мне как-то нужна группа слушателей работы для создания приложения для адресной книги? Моя доброта...