В первый раз я услышал о 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). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер

Наверное, про Event Sourcing слышал каждый, кто хоть раз пересекался с темой CQRS и DDD. Это подход хранения данных, при котором вместо конечного результата храниться череда записей о событиях происшедших с некоторой сущностью. На сайте Мартина Фаулера есть подробное описание, а мы же остановимся на фундаменте, основных «печенюшках», а также проблемах в его применении.

Перевод статьи опубликованной на Eventsourcing Publications. Статья описывает некоторые из идей примененных в проекте Eventsourcing.

Если вы читали статью Фаулера или подобные источники на тему event sourcing, у вас в мозгу могла остаться вот приблизительно такая картинка:



Общая идея такого подхода заключается в том, что пользователь (или любая другая внешняя система) генерирует команды, мы их обрабатываем, складывая полученные события в event store и обновляя «состояние мира» в базе данных, данные из которой запрашивает пользователь.

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

Добро пожаловать в серию статьей «Марсоход», где мы будем использовать следующие практики:

• Monolithic Repositories — MonoRepo (Монолитные репозитории)
• Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
• Event Sourcing — ES (События как источник)
• Test Driven Development — TDD (Разработка через тестирование)

В этой вводной статье мы просто обозначим спецификации нашего марсохода.

Примечание. Этот пример является адаптированной для нужд серии статей версией упражнения, представленного на Dallas Hack Club, который сейчас, к сожалению, лежит.


Но сначала, давайте кратко пройдемся по упомянутым выше терминам.

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

• Monolithic Repositories — MonoRepo (Монолитные репозитории)
• Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
• Event Sourcing — ES (События как источник)
• Test Driven Development — TDD (Разработка через тестирование)

Cначала нам нужно инициализировать наш проект.

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

• Monolithic Repositories — MonoRepo (Монолитные репозитории)
• Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
• Event Sourcing — ES (События как источник)
• Test Driven Development — TDD (Разработка через тестирование)

Ранее мы создали пакет навигации, теперь можно приступать к разработке первого варианта использования:

Марсоход должен будет сначала приземлиться в заданном положении. Положение состоит из координат (X и Y, являющихся целыми числами) и ориентации (строковое значение north, east, west или south).

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

• Monolithic Repositories — MonoRepo (Монолитные репозитории)
• Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
• Event Sourcing — ES (События как источник)
• Test Driven Development — TDD (Разработка через тестирование)

В предыдущих частях мы создали пакет навигации, а в нем LandRover класс, который валидирует входные параметры для нашего первого способа использования:

Марсоход должен будет сначала приземлиться в заданном положении. Положение состоит из координат (X и Y, являющихся целыми числами) и ориентации (строковое значение north, east, west или south).

Сегодня мы будем рефакторить LandRover:

В последнее время стала популярна концепция Omnichannel, когда чтобы улучшить качество обслуживания клиентов, различные каналы продаж интегрируются в один. И не важно как и где совершается продажа, для продавца имеет смысл объединить все каналы сбыта для того, чтобы выполнить заказ. На практике это означает, что неважно клиент пришел к вам оффлайн, сделал заказ на сайте, в мобильном приложении или в телефонном режиме — вы должны использовать все доступные средства для его выполнения. И для вас, как для продавца, каждый отдельный канал не должен представлять большой разницы. Презентация omni channel на примере Франкфуртского аэропорта (англ.).

Для интеграции описанной выше, со стороны продавца очень важно иметь возожность интегрировать уровни запасов товаров. Потому что инфраструктура розничной торговли может быть достаточно сложной и объединять внешние склады, магазины, магазины с возможностью заказа товаров в магазин (store pick-up), дропшиппинг (схема торговли, при которой Вы продаёте изделия фирмы-поставщика, которая сама пересылает их покупателю от Вашего имени, а Вы только принимаете от покупателя деньги).

Итак, после постановки требований описанной в части 1 можно перейти к проектированию системы.

Основная наша задача в проектировании, как это понятно из названия статьи, добиться разделения интерфейсов на Query и Command, чтобы впоследствии разделить бизнес сценарии на те, которые будут читать данные (Query интерфейсы) и на те, которые будут изменять данные (Command интерфейсы). А также обеспечить минимальное время ожидание (latency) на обновление данных, доступных через Query, после того как мы изменили данные через Command.

В данной статье будет рассмотрен Service Layer в Magento 2 и сервисы (API интерфейсы) для управления сущностями, которые были описаны в предыдущей статье, посвященной проектированию и выделению доменных сущностей для системы управления складом (Inventory).

Обзор фреймврока Axonframework

Axonframework это фреймфорк реализующий несколько принципов и паттернов проектирования такие как:

CQRS – разделяет обработку запросов на чтение и запись данных
Event Sourcing – это когда состояние приложения хранится как цепочка событий
DDD Aggregate – доменный объект (domain object) который хранит состояние

Один из недостатков хранения конечного состояния приложения в виде цепочки событий – это количество хранимых и обрабатываемых событий. К счастью, Axonframework позволяет создавать снимок событий (snapshot event), который содержит в себе результат нескольких событий (domain event).

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

Что может заставить такую большую компанию как Lamoda с отлаженным процессом и десятками взаимосвязанных сервисов существенно менять подход? Мотивация может быть совершенно разная: от законодательной до присущего всем программистам желания экспериментировать.

Но это вовсе не значит, что нельзя рассчитывать на дополнительную выгоду. В чем конкретно можно выиграть, если внедрить events-driven API на Kafka, расскажет Сергей Заика (fewald). Про набитые шишки и интересные открытия тоже обязательно будет — не может эксперимент без них обойтись.



Disclaimer: Это статья основана на материалах митапа, который Сергей провел в ноябре 2018 года на HighLoad++. Живой опыт Lamoda работы с Kafka привлек слушателей не меньше, чем на другие доклады из расписания. Нам кажется, это отличный пример того, что всегда можно и нужно находить единомышленников, а организаторы HighLoad++ и дальше будут стараться создавать располагающую к этому атмосферу.

Здравствуйте, уважаемые читатели Хабра. Меня зовут Рустем и я главный разработчик в казахстанской ИТ-компании DAR. В этой статье я расскажу, что нужно знать перед тем, как переходить на шаблоны Event Sourcing и CQRS с помощью Akka toolkit.

Примерно с 2015 года мы начали проектировать свою экосистему. После анализа и опираясь на опыт работы со Scala и Akka, решили остановиться на Akka toolkit. У нас были и удачные реализации шаблонов Event Sourcing c CQRS и не очень. Накопилась экспертиза в этой области, которой я хочу поделиться с читателями. Мы рассмотрим, как Akka реализует эти паттерны, а также какие инструменты доступны и поговорим о подводных камнях Akka. Надеюсь, что после прочтения этой статьи, у вас будет больше понимания рисков перехода на Akka toolkit.

Привет, Хабр!

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

Перевод статьи подготовлен для студентов профессионального курса «Framework Laravel»

---

Фрек ван дер Хертен (Freek Van der Herten) и команда Spatie долго трудились над Laravel Event Projector, пакетом, позволяющим применять концепцию порождения событий (Event Sourcing) во фреймворке Laravel. И вот наконец доступна первая стабильная версия (v1.0.0)!

Вы можете установить Event Projector в свой проект при помощи composer и благодаря автоматическому обнаружению пакетов в Laravel приступить к работе сразу же после публикации миграций пакета и конфигурирования!

Одной из причин популярности микросервисов является возможность автономной и независимой разработки. По сути микросервисная архитектура — это размен возможности автономной разработки на более сложный (по сравнению с монолитом) деплой, тестирование, дебаг и мониторинг. Но нужно учитывать, что микросервисы не прощают ошибок разделения ответственности. При неправильном разделение обязанностей возникают частые зависимые изменения в разных сервисах. И это намного больнее и сложнее, чем согласованные изменения в рамках разных модулей или пакетов внутри монолита. Согласованные изменения в микросервисах осложняется согласованной выкладкой, деплоем, тестированием и т.д.

И хотелось бы рассказать о различных паттернах и антипаттернах разделении ответственностей на микросервисы.

Пользователи 2ГИС каждый день помогают нам поддерживать точность данных: сообщают о новых компаниях, добавляют дорожные события, загружают фото и пишут отзывы. Раньше мы могли поблагодарить их только словами или устроить розыгрыш подарков. Но слова со временем забываются, а подарки достаются далеко не каждому. Поэтому мы решили сделать так, чтобы все неравнодушные к 2ГИС люди видели свой вклад в продукт и нашу за это благодарность.

Так появились награды — виртуальные медальки, которые мы начисляем за разного рода задания: загрузить фото в карточки кафе, написать отзывы о театрах, уточнить время работы организаций и так далее. Заработанные награды пользователи видят в личном профиле 2ГИС и на вкладке «Мой 2ГИС» в мобильном приложении. Там же мы показываем, сколько осталось до следующего достижения.

Чтобы реализовать эту фичу, мы научились обрабатывать поток событий объемом 500 тысяч записей в час (местами — до 50 тысяч в секунду) и анализировать данные из нескольких сервисов. А еще — добавили немного метапрограммирования для того, чтобы упростить конфигурирование при разработке новых наград.

Вместе с Rapter расскажем, что находится под капотом процесса выдачи наград.

Kafka Streams — это Java-библиотека для анализа и обработки данных, хранящихся в Apache Kafka. Как и в любой другой платформе потоковой обработки, она способна выполнять обработку данных с сохранением и/или без сохранения состояния в режиме реального времени. В этом посте я попытаюсь описать, почему достижение высокой доступности (99,99%) проблематично в Kafka Streams и что мы можем сделать для того, чтобы ее достичь.

Что нам нужно знать

Прежде чем описывать проблему и возможные решения, давайте рассмотрим основные концепции Kafka Streams. Если вы работали с API-интерфейсами Kafka для консьюмеров/продьюсеров, то большинство из этих парадигм вам уже знакомы. В следующих разделах я попытаюсь в нескольких словах описать хранение данных в партициях, перебалансировку групп консьюмеров и как основные концепции Kafka клиентов вписываются в библиотеку Kafka Streams.

Kafka: Партицирование данных

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

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