Чистая архитектура ASP.NET Core 7

#excalib #cleanarchitecture #aspnet
Запись на личную консультацию - t.me/excalib_a...
Всем кусь 😺 Часто возникают вопросы про чистую архитектуру, потому что не все её до конца понимают! На самом деле всё проще, чем вам кажется, и я постараюсь вам это объяснить.🎉💻
Telegram channel: t.me/excalib_c...
Telegram chat: t.me/excalib_chat
Vk: excalib88
CleanCoder: blog.cleancode...
Крутая статья про чистую архитектуру: habr.com/ru/co...
Template ASP.NET Core 7: github.com/jas...

[@Cleannetcode]

Полностью поддерживаю совет для новичков. Что не нужно пытаться выстраивать какую то "чистую архитектуру" не разобравшись с интсрументами. Сначала нужно поднабить шишек, попробовать сделать пару тройку проектиков. А затем уже можно попробовать применять те или иный концепции из мира проектирования ПО :)

[@vasinas81]

Работаю давно по такой схеме и такой архитектуре. Теперь на вопрос "зачем так сложно?" буду давать ссылку на это видео. Спасибо автору))

[@karimkimsanbaev7932]

Tools -> Architecture diagram. Dependency rule (в юз кейса интерфейс IRepository) и Data flow (По интерфейсу обращаемся к DBRepository по интерефейсу) это просто абсолютно разные вещи. Юз кейсы не знают, что мы обращаемся именно к DB, поэтому депенденси рул не нарушается. А с точки зрения голых данных мы уходим в инфраструктуру. В общем тут лучше 1 пример, вместо 1000 слов. Ключевая проблема обсуждений архитектуры, много слов и правил и ни одного боевого примера) Спасибо за пример в этом видео

[@Excalib]

Спасибо, согласен, отлично замечание! (у меня эта диаграмма чуток по-другому называется) ibb.co/rHzrg6Q (моя диаграмма)

[@perwyj]

Удивительно, что столь полезное видео, имеет так мало просмотров🤔 Спасибо большое за годный контент!

[@Excalib]

Спасибо!

[@zmqpkyf]

как по мне чистая архитектура тесно связана с ддд впринципе, отсюда выходит что слой enterprice это доменные модели, слой use cases служит в простонародье как application, все остальное уже (controllers, gateways, presenters) является слоем UI, все остальное это зависимости

[@sergbo3114]

12:20 Ну это можно сказать проще. Вызывать и зависеть, это разные вещи. Например интрефейсы и DI по сути обрывают классовые зависимости, но оставляют вызовы.

[@МаксимВеснин-и6э]

Спасибо тебе, друг! 8 лет разработки, но до меня не доходило до конца

[@Excalib]

Как я тебя понимаю:)))

[@sergeysaviiskyi7329]

Мужик, спасибо большое! Одно из лучших объяснений на русском!

[@nouchance]

Spasibo bratan ❤

[@zdludz]

Cпасибо большое за видео!! Можешь пожалуйста снять видео про библиотеку AutoMapper?

[@Excalib]

Думаю сниму)

[@zdludz]

@@Excalib спасибо большое!

[@НикитаКопылов-у9л]

однозначно лайк, броу!

[@Excalib]

сяп!

[@clutchmeisteryo9831]

В каком слое хранить Dto и конфигурацию маппера?

[@Excalib]

Смотря для какого слоя созданы дто и для какого слоя созданы правила маппинга, например если Dto аля GetUserRequest, то такая dto создана для слоя UI, тогда эта дтоха будет лежать в UI слое в проекте Web, и конфигурация для маппинга этой сущности тоже там же, а если это бизнесовая дтоха например для маппинга из Application слоя в Domain, то хранится она должна в Application и конфигурация тоже

[@arvpro8970]

Добрый день. А где и как хранить фоновые службы? Например какая та очередь задач, скажем bull. Для каждой очереди свой процессор, который выполняет что-то. Как вызывать фоновые службы чтобы они начали работать и запускали use cases? Понятно с API вызов идет напрямую. А без вызова как?

[@Excalib]

Добрый! Не очень понимаю что такое хранить фоновые службы, я бы вообще делал фоновые службы как отдельный сервис или хотя бы запускаемый проект, просто чтоб было удобно масштабировать

[@arvpro8970]

@@Excalib например мы кладем задачу отправки email, и отправка происходит воркером. Вот фоновый сервис

[@scc-6]

Мне бы асп.Кор понять, для начала((

[@СергейДовгалев-ц1щ]

поймешь. Не все сразу.

[@LAV451]

Не уверен что интерфейс должен находится хрен знает где от свое реализации. Обычно разработчик пишет компонент и представляет интерфейс для всех желающих написать своё расширение. А теперь представь что ты в своём проекте написал какой-то интерфейс и предлагаешь разработчику стороннего проекта его имплеминтировать в своём проекте. Культурный просто промолчит, а я бы послал куда подальше. Вот компонент, вот интерфейс. Тебя ведь никто не заставляет его имплементировать, мы просто указываешь его в своих зависимостях. Короче, пересмотри ещё раз своё видео и обрати внимание на слои, зависимость между ними и как эта зависимость реализуется в коде. Дизлайк. Бред полный!

[@Excalib]

Спасибо, ваше мнение очень ценно!

[@АлексейМиллер-щ7ч]

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

[@LAV451]

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

[@АлексейМиллер-щ7ч]

Можно делить на dll, можно не делить. Я бы делил.

[@Excalib]

:D

[@whisper399]

а просто тыкнуть в браузере перевести на русский не? а не объясняться пол видоса, что плохо знаешь английский

[@Excalib]

я просто русский тоже плохо знаю

[@whisper399]

@@Excalib "смешно", ха-ха-ха

[@xelaksal6690]

Зачем ты до человека доебался? Он тебе что-то сделал плохое? Более того он тебе видео снял, чтобы ты лучше разобрался, а ты неблагодарный токсичный чел. Не надо так. Если хочешь посоветовать или обратить внимание на что-то - делай это тактично. Иначе ты просто обесцениваешь весь видос и делаешь неприятно автору.