Резюме
в предыдущих статьяхКакие проблемы может решить DDD-CQRS?, объясните, что такое CQRS. Но бизнес-требований для применения CQRS нет. В последнее время мне нужно заняться делом по инкрементальному обновлению текста.Проанализировав требования, я пытаюсь использовать CQRS для решения этой проблемы.
анализ проблемы
Редактор текстовых страниц, объект очень большой, и он ранее сохранялся полностью. Задействованные объекты сетевой передачи относительно велики, и время ожидания OOM часто истекает, поэтому взаимодействие изменяется для сохранения только измененной части, то есть добавочного обновления.
Раньше CQRS нельзя было использовать в бизнесе, потому что после использования CQRS обслуживание данных стало крайне проблематичным. Например, я неоднократно модифицировал форму, сгенерировал N копий исторических данных об изменениях и получилПоследние данныеОбъединить эти исторические данные становится чрезвычайно проблематично. Этот бизнес можно использовать, потому что,
- Раздельная запись может эффективно уменьшить передачу данных.
- Чтение и запись могут быть разделены и расширены отдельно
- Благодаря источнику событий данные могут быть восстановлены до любой отредактированной версии.
особый дизайн
Вся система использует CQRS+Event-Sourcing для реализации
CQRS
Шаблон CQRS разделяет операции чтения данных и обновления данных с помощью разных интерфейсов. Режим CQRS может максимизировать производительность, масштабируемость и безопасность, Это также обеспечит большую гибкость для непрерывного развития системы, предотвращая конфликт команд обновления на уровне модели предметной области.
Доменная модель редактирования текста очень тонкая, нет проверки и ограничений домена, и она разделена в соответствии с данными чтения/обновления.Когда давление чтения и записи различно, в будущем ее можно разделить на разные службы и расширяется отдельно.
Поиск событий
А. Вместо сохранения последнего состояния объекта сохраните все события, сгенерированные объектом б) Получить последний статус объекта через Event Sourcing (ES);
Система разделена на три части
1. команда
Все команды модификации данных, команда обновления, команда отмены, команда перезаписи Будет постоянно храниться в CommitRepository. затем выдать сообщение о событии
2. дескриптор события
В случае редактирования текста обработка события — это, в основном, командное событие коммита слияния. В противном случае во время трассировки источника событий возникает слишком много событий обновления данных, которые необходимо обработать, что занимает слишком много времени.
3. запрос
Данные запроса, вы можете получить любые данные фиксации в соответствии с записью модификации.
Три части разделены и могут быть развернуты как единая служба или разделены на несколько служб для простоты расширения.
вопросы, требующие решения
- Как обеспечить порядок событий
Типичная проблема CQRS заключается в том, что последовательность событий на стороне производства не соответствует последовательности событий на стороне потребителя, что приводит к несогласованности данных. Как это решить?
Часть обработки команды обрабатывает все части обновления данных и создает глобально упорядоченный идентификатор фиксации, который представляет порядок обновления. То есть порядок событий на стороне производителя, но порядок, который доходит до нашей стороны потребителя, не обязательно является этим порядком. Поэтому на стороне потребителя после завершения обработки события будет обновлен последний commitid потребления. Если идентификатор фиксации текущего события меньше последнего идентификатора фиксации, событие отбрасывается.
-
Как обеспечить производительность чтения данных Часть дескриптора события объединяет фиксации, поэтому чтение данных не объединяет данные из всех измененных коммитов данных. Данные были предварительно обработаны, поэтому эффективность чтения будет значительно увеличена, а объединяемые данные можно контролировать в диапазоне от 5 до 10 коммитов.
-
Будут ли потеряны данные?
После того, как система разделена, нет гарантии транзакции, как гарантировать целостность данных.
Когда команда обновления данных написана успешно, это означает, что обновление данных прошло успешно, и данные не будут потеряны. Поскольку эти данные были сохранены, оставшаяся проблема состоит в том, чтобы прочитать коммит этих отправлений. Мы можем получить последние полные данные, объединив эти коммиты. Таким образом, даже если часть дескриптора события не работает, последние данные все еще могут быть прочитаны.
инструкция
Для этого случая до сих пор нет прикладной основы.axon, оценка в настоящее время не очень подходит, код не читается, а преимущества не очевидны. Позже подумайте, стоит ли вводить фреймворк.
серия ДДД
Как наша команда попала в DDD (1)
Landable DDD (2) — почему инженерная архитектура MVC устарела
Landable DDD (3) — Как использовать DDD для разделения микросервисов
Landable DDD (4) — Как использовать DDD для разделения микросервисов (2)
Landable DDD(5) - Тактический дизайн
Как избежать написания плохого бизнес-кода (2) Исправление DDD