Что-то намудрили со статьей, DTO и мапперы не имеют прямого отношения к CQRS, это уже из DDD части. Если вы добавляете CQRS, все что добавляется в проект, это логическое разделение методов условного сервиса (без cqrs скорее всего вы бы использовали именно сервис хранящий бизнес-логику определенной части функционала) на отдельные независимые команды. Плюс эти команды разделяются на те которые мутируют данные (Cqrs) и те которые не мутируют а только отдают (cQrs). Да, каждая команда состоит из двух файлов, Самой Command/Query и handler, но первый обычно очень тонкий и по-сути сам по себе является этим самым "DTO" только для хендлера непосредственно. И это не тот DTO о котором в статье речь. И меняется способ вызова, вы теперь не вызываете сервис который тянет другой сервис, а тот следующий, а создаете Command/Query, заполняете данными (это можно и через конструктор сразу прокинуть все) и отправляете его в шину, которая его уже запустит сама.
По итогу имеем: - строгое разделение команд/запросов, в том числе по файлам - проще разобраться в отдельном файле-команде, чем искать что-то в огромном сервисе - проще тестировать и масштабировать
Как и с DDD в целом, нужно просто понимать что это и как это использовать, а не просто внедрять все подряд, и если внедрять именно cqrs - сложностей это практически не прибавит, чего нельзя сказать о DDD в целом.
Сейчас DDD это уже база для любой разработки, что монолит что микросервисов. Неправильное разделение на контексты действительно породит кучу проблем, поэтому в DDD уделяется этому большое внимание и все специалисты говорят не делать наносервисы. Мы тоже обожглись, когда разделяли монолит решили "на будущее" сразу сделать Уведомления + Email сервис (для отправки писем) + Telegram Service (для уведов напрямую). В итоге если сразу правильно все продумали, то не плодили бы эти лишние сервисы, потому что по-сути все это контекст уведомлений и не нужно было ничего лишнего добавлять. SOLID / KISS/ DRY при этом не противоречат DDD, просто надо правильно интерпретировать эти методологии
Минус не от меня, но если честно все еще непонятно) Почему-то всегда все кто рассказывает про микросервисы приводят в примеры какие-то мудрёные реализации сложных систем не самых близких к массовому айти. Можете привести пример всё-таки на уровне абстрактного функционала соцсети?
Допустим есть у нас сообщения, есть сообщества, есть новостная лента, есть профили. Это же нормальные микросервисы или уже нано? Или если мы возьмём управление профилем пользователя, тот же Яндекс паспорт или VK ID, вроде как просто делает авторизацию и можно обозвать наносервисом, но паттерн популярен и почти все так делают. Можете придумать чтото для понимания что можно было сделать в соцсети не так, чтобы это стало наносервисом?
Я так и не понял, где в статье описывается что всё-таки такое нано сервис. Пример с салатами лучше бы заменили на реальный практический пример, хотя бы на уровне соцсети какой-нибудь где это довольно просто показать)
На самом деле почти все рекомендации также применимы к монолиту. Тем более что монолит можно положить в кластер под балансировщик с несколькими репликами, тогда и вовсе все это к нему будет также относиться. Ну и вопрос выбора монолит/микросервис это уже другая тема, если команда небольшая и серьезного роста в ближайшее время не предвидится, то на микросервисах вы можете сами себя загнать в долгую рутину. А правильно построенный монолит на DDD можно в любой момент начать разделять по микросервисам, если команда выросла и хочется независимости
Что-то намудрили со статьей, DTO и мапперы не имеют прямого отношения к CQRS, это уже из DDD части. Если вы добавляете CQRS, все что добавляется в проект, это логическое разделение методов условного сервиса (без cqrs скорее всего вы бы использовали именно сервис хранящий бизнес-логику определенной части функционала) на отдельные независимые команды. Плюс эти команды разделяются на те которые мутируют данные (Cqrs) и те которые не мутируют а только отдают (cQrs). Да, каждая команда состоит из двух файлов, Самой Command/Query и handler, но первый обычно очень тонкий и по-сути сам по себе является этим самым "DTO" только для хендлера непосредственно. И это не тот DTO о котором в статье речь. И меняется способ вызова, вы теперь не вызываете сервис который тянет другой сервис, а тот следующий, а создаете Command/Query, заполняете данными (это можно и через конструктор сразу прокинуть все) и отправляете его в шину, которая его уже запустит сама.
По итогу имеем:
- строгое разделение команд/запросов, в том числе по файлам
- проще разобраться в отдельном файле-команде, чем искать что-то в огромном сервисе
- проще тестировать и масштабировать
Как и с DDD в целом, нужно просто понимать что это и как это использовать, а не просто внедрять все подряд, и если внедрять именно cqrs - сложностей это практически не прибавит, чего нельзя сказать о DDD в целом.
Сейчас DDD это уже база для любой разработки, что монолит что микросервисов. Неправильное разделение на контексты действительно породит кучу проблем, поэтому в DDD уделяется этому большое внимание и все специалисты говорят не делать наносервисы. Мы тоже обожглись, когда разделяли монолит решили "на будущее" сразу сделать Уведомления + Email сервис (для отправки писем) + Telegram Service (для уведов напрямую). В итоге если сразу правильно все продумали, то не плодили бы эти лишние сервисы, потому что по-сути все это контекст уведомлений и не нужно было ничего лишнего добавлять. SOLID / KISS/ DRY при этом не противоречат DDD, просто надо правильно интерпретировать эти методологии
Слишком поверхностно, хотелось бы 10-часовую версию
Минус не от меня, но если честно все еще непонятно) Почему-то всегда все кто рассказывает про микросервисы приводят в примеры какие-то мудрёные реализации сложных систем не самых близких к массовому айти. Можете привести пример всё-таки на уровне абстрактного функционала соцсети?
Допустим есть у нас сообщения, есть сообщества, есть новостная лента, есть профили. Это же нормальные микросервисы или уже нано? Или если мы возьмём управление профилем пользователя, тот же Яндекс паспорт или VK ID, вроде как просто делает авторизацию и можно обозвать наносервисом, но паттерн популярен и почти все так делают. Можете придумать чтото для понимания что можно было сделать в соцсети не так, чтобы это стало наносервисом?
Я так и не понял, где в статье описывается что всё-таки такое нано сервис. Пример с салатами лучше бы заменили на реальный практический пример, хотя бы на уровне соцсети какой-нибудь где это довольно просто показать)
На самом деле почти все рекомендации также применимы к монолиту. Тем более что монолит можно положить в кластер под балансировщик с несколькими репликами, тогда и вовсе все это к нему будет также относиться. Ну и вопрос выбора монолит/микросервис это уже другая тема, если команда небольшая и серьезного роста в ближайшее время не предвидится, то на микросервисах вы можете сами себя загнать в долгую рутину. А правильно построенный монолит на DDD можно в любой момент начать разделять по микросервисам, если команда выросла и хочется независимости
32 тысячи токенов. Объёмные тексты. Ну, ладно)
Сейчас уже следует сравнивать с o1/o3-mini. 4o не актуален уже пол года как