cqrs

Xendor

Xendor - это структура .NET Core Framework, которая может быть использована для создания простого и чистого дизайна путем обеспечения единой ответственности и разделения проблем. Его расширенные функции идеально подходят для домена, управляемого дизайном (DDD), ответа на командный запрос SEGRAGATION (CQRS) и поиск событий. Xendor также имеет интеграцию RabbitMQ.

Что такое CQRS?

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

CQRS - это шаблон, на который вы применяете? Вмески? вашего сервиса/приложения, и вы можете применить его только к части вашего сервиса.

Это не CQRS

Это не в конечном итоге последовательность

Это не события

Это не обмен сообщениями

У него нет отдельных моделей для чтения и письма

Также это не использует поиск событий.

CQRS Pros & Cons

Плюсы:

• Лучшая производительность и масштабируемость вашей системы.
• Лучшая одновременная обработка доступа.
• Лучшая масштабируемость команды.
• Менее сложная доменная модель и простая модель запроса.

Минусы:

• Читать и записать модели должны быть синхронизированы.
• Затраты на техническое обслуживание и администрирование, если вы выберете два разных двигателя для чтения и для записи.
• Возможная последовательность не всегда разрешена.

Что такое поиск событий?

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

В каких системах стоит использовать поиск событий?

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

События для сорсирования и минусы

Плюсы:

• Только добавление модели отлично подходит для производительности, масштабируемости
• Нет тупиков
• События (факты) хорошо поняты бизнес -экспертом, некоторые домены по своей природе поставляются: бухгалтерский учет, здравоохранение, торговля
• Аудиторская тропа бесплатно
• Мы можем получить состояние объекта в любой момент времени
• Легко тестировать и отлаживать
• Модель данных, отделенная от модели домена
• Нет несоответствия импеданса (объектная модель против модели данных)
• Гибкость? Многие различные доменные модели могут быть построены из одного и того же потока событий
• Мы можем использовать эту модель с обратными событиями, ретроактивными событиями
• Нет больше орм? Благодаря тому, что наш объект построен из событий, нам не нужно отражать его в реляционной базе данных

Минусы:

• Не естественный способ для разработчиков управлять состоянием и построить агрегаты, требует времени, чтобы привыкнуть к
• Запрос за один агрегат немного сложнее (вы должны построить прогнозы для каждого типа запроса, который вы хотите добавить в систему),
• Изменения схемы событий намного сложнее, чем в случае реляционной модели (отсутствие стандартных инструментов миграции схемы)
• Вы должны рассмотреть вопрос о обработке версий с самого начала.

Сообщение о событиях - прогнозы

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

Проекция - это получение текущего состояния из потока событий.

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

UserAddedToaccount

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "name" : " Alejandro " ,
 "lastName" : " Moline "
}

UserVerifiedEmail

{
 "userId" : 55 ,
 "email" : " [email protected] "
}

UserUpdated

{
 "userId" : 55 ,
 "lastName" : " Molines "
}

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

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "email" : " [email protected] " ,
 "name" : " Alejandro " ,
 "lastName" : " Molines "
}

CQR с поиском событий (CQRS-ES)

Дайте звезду!

Если вы любите или используете этот проект, пожалуйста, дайте ему звезду. Спасибо!

Я нашел проблему или у меня есть запрос на изменение

Не стесняйтесь создавать проблему на GitHub. Взносы, запросы на тягу более чем приветствуются!

Xendor - Copyright © 2019 Alejandro Molines и другие участники по лицензии MIT.