Папочка Дотнета
Папочка Дотнета
Telegram

Миф о CQRS: без кафки и микросервисов

Папочка Дотнета

Я — «Папочка Разработки»: пишу о карьере .NET/C#, собесах и том, как продавать свои навыки дороже. Без воды: разборы утечек памяти, практические гайды по интервью, резюме с цифрами и честные кейсы с рынка. Плюс немного про ИИ — как делегировать ему рутину и ускорять работу. Заходи, если нужен понятный план действий, а не мотивационные лозунги.

Открыть в TelegramДругие публикации
cqrskafkaмикросервисы

Про CQRS есть ещё один миф, который стабильно пугает людей.

Если ты полез в CQRS — готовь кафку, микросервисы, отдельные базы и психолога. 🥣

На практике самый полезный CQRS вообще без всего этого. Один сервис. Одна база. Просто внутри ты перестаёшь мешать запись и чтение в одном месте.

  • Для записи — нормальная доменная логика, проверки, транзакции.
  • Для чтения — прямые запросы и DTO, без лишней философии.

Никакой магии. Просто код, который наконец-то понятно читать.

Спасибо за реакции. Продолжаем короткие заметки на технические темы 🥰

Дискуссия

Sergey Nazarov
Tsimafei Khavanski
что такое этап проектирования - это когда нейронке пишешь чтоб она основу накидала или как?
Конгда проектируешь свой сервис =) Не знаю, что ты подразумеваешь под основой.
Sergey Nazarov
Tsimafei Khavanski
берёшь метод ef'а где можно сырой sql писать и всё
Можно и так, но там тоже есть методы с маппингом и без. Нужно смотреть конкретный кейс.
Ayrat I
Tsimafei Khavanski
а почему собственно не сделать один контроллер , один контекст и везде юзать ef ?
Про контекст и ef - это по желанию. Про контроллер - разделение контекста. Проще же читать код, если там нет мусора, который не относится к задаче. По итогу будут разные контракты, модели, сервисы для гет и пост
Brueder
"Никакой магии. Просто код, который наконец-то понятно читать." От подобных текстов веет gpt😁
Aleksandr Alekseev
Brueder
"Никакой магии. Просто код, который наконец-то понятно читать." От подобных текстов веет gpt😁
Я еще и тире сам люблю использовать
😁1
Tsimafei Khavanski
Ayrat I
Про контекст и ef - это по желанию. Про контроллер - разделение контекста. Проще же читать код, если там нет мусора, который не относится к задаче. По итогу будут разные контракты, модели, сервисы для гет и пост
так тогда уже без разницы, делим ли мы по чтению/записи. Можно делить просто по разным операциям
Brueder
Aleksandr Alekseev
Я еще и тире сам люблю использовать
Это тоже заметил)
Ayrat I
Tsimafei Khavanski
так тогда уже без разницы, делим ли мы по чтению/записи. Можно делить просто по разным операциям
Можно и так. Просто базово паттерн про быстрые чтения и медленную запись. Поэтому базово с этого начинаешь, дальше смотришь по ситуации
Глеб
Tsimafei Khavanski
то есть cqrs - сделай разные модельки рид и райт, потому что скорее всего тебе в них разные данные нужны будут. Глубоко
Суть не в разных данных, а в разных подходах. Выше Сергей верно отметил на примере с DDD. Для записи тебе нужно провалидировать входные данные, загрузить тяжёлый агрегат, провести бизнес проверки и только после этого обновить агрегат. Для чтения тебе нужно просто сходить в базу и прочитать данные. Это позволяет сделать разные интерфейсы для команд и запросов, что позволяет двумя разными способами работать с данными. В том же MediatR можно разные пайплайны навешать на чтение и запись, как пример.
Присоединиться к обсуждению →

Читайте так же