Денис Цветцих - 9 способов улучшить архитектуру вашего проекта при помощи CQRS и vertical slices
Vložit
- čas přidán 7. 09. 2021
- Ближайшая конференция - DotNext 2024, 10 - 11 сентября, Москва + online
Подробности и билеты: jrg.su/x2GKnA
- -
Логика большинства проектов реализуется «горизонтально» в виде слоя ApplicationServices. Однако существует альтернативный подход, когда для каждого юзкейса создается отдельный класс-хендлер. Чаще всего такой подход используется вместе с CQRS, когда система распиливается на стеки чтения и записи ради повышения производительности. Джимми Богард назвал этот же подход vertical slices. Многие разработчики слышали о нем, но не используют, так как не могут ответить на вопрос: «стоит ли использовать хендлеры, если мы не боремся за производительность при помощи CQRS?»
В докладе Денис покажет 9 преимуществ, которые дают вертикальные хендлеры/слайсы по сравнению с привычными горизонтальными слоями. А также он поделится опытом перехода с сервисов на слайсы. - Věda a technologie
использую CQRS и Vertical Sliced в любых проектах, потому что это упрощает восприятие системы и ориентацию в системе.
облегчение на лицо (с)
Падажжите, они родственники или нет?
9 преимуществ мотоцикла перед велосипедом: явные: едет быстрее, он мощнее, вы раньше прибудете на место, условные: на вас есть шлем, на вас есть защита, и побочные преимущества: колёса шире, больше спиц, есть бибикалка, есть зеркальце. Минусов у мотоцикла практически нет, только ветер сильнее. Мужики, у вас лекция ради лекции, просто чтобы гонорар отработать? Я же смотрю на вас, как на супер-профи в программировании, в надежде узнать что-то полезное, а после такого ролика браться за новое уже не хочется. Тема не раскрыта! (минус полтора часа с пересмотрами)
Да ладно !!!!!!!!!!!!!!!. Два брата!!!
уровень спикеров в очередной раз огорчил(( примеры все как 1 притянуты за уши, про зависимости - поржал от души эксперт так эксперт
Парни, что за терминология? Нахватались терминов не понимая их. Юскейс нельзя вызвать, тем более из юскейса. Use case это как бы типичная ситуация или поведение, вариант, случай или их описание, сценарий. Не код или реализация.
ru.wikipedia.org/wiki/%D0%A1%D1%86%D0%B5%D0%BD%D0%B0%D1%80%D0%B8%D0%B9_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F
К примеру, Delete как метод объекта, это не юскейс. А вот вызов этого метода при каких-то условиях или по какому-то сценарию, это уже юскейс, но опять же не на уровне Delete. Delete не актор, по крайней мере не в указанном примере. И даже если Delete вызывает другой Delete, тут нет юскейса, это выполнение внешнего сценария.
терминов конечно и правда много, и порой они только все портят. Но в данном случае use case - вариант использования, и докладчик вполне верно его употреблял.
Пример с Delete верный, просто нужно понять, что докладчик рассказывал именно про слой Application где описаны как раз таки сценарии. В данном случае мы видим сценарии описанные в виде commands and queries (CRQS).
@@Cleannetcode Попробую по другому пояснить. У спикера юзкейс, это конкретная реализация. Вот унего даже "код юскейса" есть. Delete - юскейс для объекта. Но не конкретный метод объекта. Для одного юскейса может быть несколько реализаций метода Delete. Если вы будете делать так, как он, то вам придется придумывать обобщающий реализации термин, типа "юскейс верхнего уровня". Это бардак. Вот у него "юскейс вызывает юскейс". Ну и как вам, понятно кто на ком стоял?
@@vadim_b. хмм, звучит здраво. Спасибо :)
+1 правильное наименование проблемы - половина решения!