Ощущение что человек рассказывает как он не понимает слоёную архитектуру. Не подумайте, я её не защищаю, у неё есть минусы, но не те что обсуждаются. А те что обсуждаются - максимально надуманны: 1. Business layer - всё что касается логики приложения, это НЕ API (входная точка приложения, запросов и тд), и не DataAccess (который обеспечивает доступ до данных). И чтобы понять это, сперва опишите что такое API и DataAccess - всё остальное идёт в BL. 2. Направление зависимостей - по классике всегда в одну сторону, API => BL => DAL. Это может породить другие проблемы, например BL начинает зависеть от EntityFramework, что может быть не приятной вещью. И тогда можно развернуть в сторону бизнес логики, API => BL
а вот вопрос: API -> BL < DAL. Есть объект BL Book. Как правильно реальзовать его сохранить если BL не знает про DAL? BL имплементит интерфейсы IReadable/ISaveable? Которые имплементяться в DAL слое?
@@user-dzimka по правилам IoC всё так и есть - в BL определяются интерфейсы доступа данных, а в DAL они имплементируются. Как их делать - это уже вопрос к команде - хоть IReadable/ISaveable (что звучит как лютые оверкилл), хоть простой IBookDataService { Book GetBook(id); void SaveBook(model); } Соответственно BL только знает о том, что кто-то умеет сохранять книги, а кто именно и как реализовано это - уже BL не важно, тем самым избавляетесь от зависимости от DAL и его классов, можно менять реализации одних БД на другие или вообще Rest-клиенты. В общем всё то, о чём неоднократно говорилось в Clean Architecture
@@user-dzimka да, все верно с интерфейсами . В следующем ролике про clean architecture как раз про это и расскажу. А про слоенку, о том и речь, что направление зависимостей четко не регламентировано. В итоге одна имплементация может очень сильно отличаться о другой
@@StormB87 спасибо. А вообще по видео мое мнение - эта архитектура должна жить, чтобы джуны и мидлы хоть на чем-то тренировались. Это потом с опытом приходит понимание проблем этой архитектуры и поиск знаний что же дальше. Кстати заметил тенденцию что популярность набирает упрощение.
Формат супер. Лучше заходит, чем заранее подготовленные слайды - чувствуется больше интерактива. Для себя уже давно пришел к связке DDD + Clean Arch. Пока лучше для бизнес сервисов архитектуры не нашел.
Спасибо за поддержку! В следующем ролике как раз про clean architecture расскажу. Так же как и вы, я пришел к тому что clean architecture + ddd отлично подходят к большинству проектов
@@StormB87 Здорово! Буду ждать видео. Причем, не важно на каком языке реализован сервис. Последние сервисы с применением DDD + Clean Arch писали на Go. На нем, благодаря специфики работы с пакетами, некоторые вещи получается реализовывать удобнее чем на Java
Ощущение что человек рассказывает как он не понимает слоёную архитектуру.
Не подумайте, я её не защищаю, у неё есть минусы, но не те что обсуждаются. А те что обсуждаются - максимально надуманны:
1. Business layer - всё что касается логики приложения, это НЕ API (входная точка приложения, запросов и тд), и не DataAccess (который обеспечивает доступ до данных). И чтобы понять это, сперва опишите что такое API и DataAccess - всё остальное идёт в BL.
2. Направление зависимостей - по классике всегда в одну сторону, API => BL => DAL. Это может породить другие проблемы, например BL начинает зависеть от EntityFramework, что может быть не приятной вещью. И тогда можно развернуть в сторону бизнес логики, API => BL
а вот вопрос: API -> BL < DAL. Есть объект BL Book. Как правильно реальзовать его сохранить если BL не знает про DAL? BL имплементит интерфейсы IReadable/ISaveable? Которые имплементяться в DAL слое?
@@user-dzimka по правилам IoC всё так и есть - в BL определяются интерфейсы доступа данных, а в DAL они имплементируются. Как их делать - это уже вопрос к команде - хоть IReadable/ISaveable (что звучит как лютые оверкилл), хоть простой IBookDataService { Book GetBook(id); void SaveBook(model); }
Соответственно BL только знает о том, что кто-то умеет сохранять книги, а кто именно и как реализовано это - уже BL не важно, тем самым избавляетесь от зависимости от DAL и его классов, можно менять реализации одних БД на другие или вообще Rest-клиенты. В общем всё то, о чём неоднократно говорилось в Clean Architecture
Спасибо большое за обстоятельный комментарий. По делу. Я как доберусь до физической клавиатуры вам отвечу так же обстоятельно ;)
@@user-dzimka да, все верно с интерфейсами . В следующем ролике про clean architecture как раз про это и расскажу.
А про слоенку, о том и речь, что направление зависимостей четко не регламентировано. В итоге одна имплементация может очень сильно отличаться о другой
@@StormB87 спасибо. А вообще по видео мое мнение - эта архитектура должна жить, чтобы джуны и мидлы хоть на чем-то тренировались. Это потом с опытом приходит понимание проблем этой архитектуры и поиск знаний что же дальше. Кстати заметил тенденцию что популярность набирает упрощение.
Надо было сказать «все понимают слоеную архитектуру по разному, а я (ведущий) вообще первый раз про такое слышу»
формат подачи мне заходит
Спасибо! Небыл уверен что такой формат с кривыми диаграммами зайдет :) искренне спасибо!
Формат супер. Лучше заходит, чем заранее подготовленные слайды - чувствуется больше интерактива. Для себя уже давно пришел к связке DDD + Clean Arch. Пока лучше для бизнес сервисов архитектуры не нашел.
Спасибо за поддержку! В следующем ролике как раз про clean architecture расскажу. Так же как и вы, я пришел к тому что clean architecture + ddd отлично подходят к большинству проектов
@@StormB87 Здорово! Буду ждать видео. Причем, не важно на каком языке реализован сервис. Последние сервисы с применением DDD + Clean Arch писали на Go. На нем, благодаря специфики работы с пакетами, некоторые вещи получается реализовывать удобнее чем на Java
Подскажите пожалуйста, на каком устройстве вы рисуете?
Огонь ❤
Спасибо!
DAL давно уже переименовали в Infrastructure.... :( Зачем такую пургу нести?....
Ряд проблем надуманные.., ИМХО конечно