Redux — это отличное средство для управления состоянием сложных фронтенд-приложений. Автор материала, перевод которого мы сегодня публикуем, собирается найти ответ на вопрос о том, можно ли воспользоваться возможностями Redux в серверной среде.
Читать полностью »
Рубрика «event sourcing» - 2
Можно ли использовать Redux на сервере?
2019-01-28 в 9:46, admin, рубрики: cqrs, event sourcing, redux, Блог компании RUVDS.com, разработка, Разработка веб-сайтов, Серверное администрированиеСнимки событий в Axonframework 3, улучшаем производительность
2019-01-09 в 10:44, admin, рубрики: axonframework, cqrs, event sourcing, java, snapshot event, snapshottingОбзор фреймврока Axonframework
Axonframework это фреймфорк реализующий несколько принципов и паттернов проектирования такие как:
CQRS – разделяет обработку запросов на чтение и запись данных
Event Sourcing – это когда состояние приложения хранится как цепочка событий
DDD Aggregate – доменный объект (domain object) который хранит состояние
Один из недостатков хранения конечного состояния приложения в виде цепочки событий – это количество хранимых и обрабатываемых событий. К счастью, Axonframework позволяет создавать снимок событий (snapshot event), который содержит в себе результат нескольких событий (domain event).
Читать полностью »
Система управления складом с использованием CQRS и Event Sourcing. Service Layer
2017-08-14 в 21:03, admin, рубрики: catalog, catalog inventory, command, cqrs, event sourcing, inventory, Magento, magento 2, MSI, php, service contracts, service layer, Проектирование и рефакторинг, Разработка под e-commerce, Совершенный код
В данной статье будет рассмотрен Service Layer в Magento 2 и сервисы (API интерфейсы) для управления сущностями, которые были описаны в предыдущей статье, посвященной проектированию и выделению доменных сущностей для системы управления складом (Inventory).
Читать полностью »
Система управления складом с использованием CQRS и Event Sourcing. Проектирование
2017-07-19 в 9:21, admin, рубрики: CatalogInventory, command, cqrs, event sourcing, Eventual consistency, inventory, Magento, magento 2, MSI, php, Query, service layer, Проектирование и рефакторинг, Разработка под e-commerce, Совершенный код
Итак, после постановки требований описанной в части 1 можно перейти к проектированию системы.
Основная наша задача в проектировании, как это понятно из названия статьи, добиться разделения интерфейсов на Query и Command, чтобы впоследствии разделить бизнес сценарии на те, которые будут читать данные (Query интерфейсы) и на те, которые будут изменять данные (Command интерфейсы). А также обеспечить минимальное время ожидание (latency) на обновление данных, доступных через Query, после того как мы изменили данные через Command.
Читать полностью »
Марсоход, Введение
2016-11-08 в 12:00, admin, рубрики: cqrs, DDD, event sourcing, mars rover series, mono repo, php, tdd, Алгоритмы, Программирование, Разработка веб-сайтов, метки: mars rover series, mono repo
Добро пожаловать в серию статьей «Марсоход», где мы будем использовать следующие практики:
- Monolithic Repositories — MonoRepo (Монолитные репозитории)
- Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
- Event Sourcing — ES (События как источник)
- Test Driven Development — TDD (Разработка через тестирование)
В этой вводной статье мы просто обозначим спецификации нашего марсохода.
Примечание. Этот пример является адаптированной для нужд серии статей версией упражнения, представленного на Dallas Hack Club, который сейчас, к сожалению, лежит.
Но сначала, давайте кратко пройдемся по упомянутым выше терминам.Читать полностью »
Ленивый event sourcing или как жить сегодняшним днем
2016-05-16 в 21:53, admin, рубрики: cqrs, event sourcing, java, open source, Программирование, Проектирование и рефакторингПеревод статьи опубликованной на Eventsourcing Publications. Статья описывает некоторые из идей примененных в проекте Eventsourcing.
Если вы читали статью Фаулера или подобные источники на тему event sourcing, у вас в мозгу могла остаться вот приблизительно такая картинка:
Общая идея такого подхода заключается в том, что пользователь (или любая другая внешняя система) генерирует команды, мы их обрабатываем, складывая полученные события в event store и обновляя «состояние мира» в базе данных, данные из которой запрашивает пользователь.
Этот подход выглядит просто и красиво. У нас есть достаточно данных чтобы «переигрывать» события, у нас есть откуда запрашивать данные о состоянии мира и мы можем использовать проверенные временем базы данных. С другой стороны, я обратил внимание что я хотел немного другого от концепции event sourcing. Мне хотелось избежать предугадывания будущего и эта модель как-то не очень подходила, потому что мне приходилось записывать обновленное состояние в мою базу данных «для чтения».
Интервью с Дино Эспозито, автором книги «Microsoft .NET: Architecting applications for the enterprise»
2014-07-28 в 10:21, admin, рубрики: .net, cqrs, DDD, event sourcing, framework, Блог компании Luxoft, проектирование, Проектирование и рефакторингДИНО ЭСПОЗИТО
«А что если», Event Sourcing
2013-04-28 в 18:50, admin, рубрики: .net, event sourcing, архитектура приложений, Программирование, метки: event sourcing, архитектура приложений Наверное, про Event Sourcing слышал каждый, кто хоть раз пересекался с темой CQRS и DDD. Это подход хранения данных, при котором вместо конечного результата храниться череда записей о событиях происшедших с некоторой сущностью. На сайте Мартина Фаулера есть подробное описание, а мы же остановимся на фундаменте, основных «печенюшках», а также проблемах в его применении.
Читать полностью »
Введение в CQRS + Event Sourcing: Часть 1. Основы
2012-06-30 в 20:01, admin, рубрики: .net, cqrs, DDD, domain-driven design, event sourcing, Веб-разработка, Проектирование и рефакторинг, метки: cqrs, DDD, domain-driven design, event sourcingВ первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. И этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.
Вообще многие говорят о CQRS как о паттерне проектирования. На мой взгляд он слишком сильно влияет на общую архитектуру приложения, что бы называться просто “паттерном проектирования”, поэтому я предпочитаю называть его принципом или подходом. Использование CQRS проникает почти во все уголки приложения.
Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.
Начнем с CQRS
Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер
Читать полностью »