а практика, хочется посмотреть как любой проект перенести).. Запиши плиз как к примеру у тебя же есть blog на ларке перетащить на порто) было бы очень интересно
Дмитрий, благодарю за подробные и интересные объяснения. Как всегда всё доступным языком и по полочкам разложено. Отправил донат, надеюсь он до тебя дошел!))) Очень приятно, когда просьбы услышаны и интересующие темы раскрываются. Блог был очень достойно разобран в чудесном курсе по Laravel, может в этот раз разберём слегка усложнённый интернет магазин? Например про ювилирку, там от размера кольца может меняться торговое предложение. Это было бы интересно посмотреть как логика разложенная с помощью паттерна Porto позволяет использовать сложные структуры данных.
В Apiato это решено так. Все таски и экшоны вызываются методом call(). Есть артисан команда которая показывает какой контейнер от какого зависит беря во внимание вызовы call(). php artisan apiato:list:dependencies app/Containers/{container-name}
Так а чем это по сути может помочь, от знания зависимостей проект дробится лучше не станет. В конце концов просто окажется, что через череду зависимостей у нас будет божественный контейнер который будет обращаться ко всем или критическому числу тасков в других контейнерах.
Контроль зависимостей. Чтобы вовремя предупредить нарушение архитектурных границ. Полезно когда большая команда и простым ревью нарушение можно пропустить.
@@DmitryAfanasyev Это понятно. Просто выше было написано "в apiato это решено так". То есть либо шла речь исключительно про отслеживание зависимостей либо, как я понял, в общем о сокращение связывания. И архетектурно, на мой взгляд, это никак не помагает сократить связанность. Решение с теме же фасадами выглядит более контролируемым, а в целом, как впрочем и всегда, нужен еще один управляющий слой абстракции.
Как ни странно порто решил большинство проблем со структурой моего кода. До твоего курса пребывал его использовать, но как то не зашло. Сейчас пересмотрев курс, внедряю порто в новый проект. И скажу что очень доволен. Спасибо
Коллеги программисты, доброго времени суток. Вопрос о разделении монолита с архитектурой Porto на микросервисы. Как вынести контейнеры, чтобы они друг о друге ничего не знали, и их взаимодействие настроить через RabbitMQ или Centrifugo? (сейчас у нас на некоторых проектах используется Centrifugo, взаимодействие микросервисов происходит через сокеты).
@@ДмитрийЖунёв-я7г ну по конкретней то приведите пример) связанность тоже разного рода бывает. может у вас одна база общая к примеру и вы этим там все зхаваязали.
Спасибо за уроки. Лайк, донат, вечная подписка. Жду продолжений других плейлистов. По подходу Porto возникло несколько вопросов. 1. Если нужно добавить колонку в таблицу и есть два контейнера, для админки и для пользователей, то в какой контейнер класть миграцию? Если в какой то один, то если в будущем выпилить его, то другой контейнер об этом и не узнает. 2. Для фронтэнда при использовании общих лейаутов для вьюх как быть? Выносить на уровень коробля или использовать менеджеры про которые вы упоминали? Посмотрел Апиато, у них для каждого контейнера свой html и стили в базовой архитектуре. 3. И еще про фронтэнд. Стили и скрипты по контейнерам тоже возможно разложить? И не добавлять каждый раз в webpack.mix.js а как-то автоматизировать этот процесс. Еще раз спасибо за вашу работу.
Развязывать нужно через интерфейсы, внутри секции должна быть большая связность, снаружи слабая (Low Coupling (низкая связанность) и High Cohesion (высокое зацепление)) Доклады на эту тему (видео) Сергей Протько "Связать и развязать" (видео) PHP NN #4: два доклада для поклонников Symfony и сочувствующих с 1:05:00 (статья) Модульный PHP монолит: рецепт приготовления
Как итог сам шаблон порто может быть разбит на микросервисы и быть собранным на этих же микросервисах зависимости коробля правда придется занести в контейнер но это дело уже такое
Скажите пожалуйста, а есть ли реальный пример на худо-бедно большом интрепрайз проекте? Где будет бизнес логика, довольно сложная или с хитрецой, где будет много взаимодействий. вычислений и построений классов и взаимодействий по логике. .. Потому что методы в стиле findUserById, findUserbyEmail - это на столько мелко, что ради такого переделывать обычную структуру совершенно не стОит. Любой CRUD (а это в примерах по сути и есть) любой фреймворк за 5 минут генерирует. А структура ради структуры - ну такое...)) Интересно увидеть реально большой и практический жизненный пример с "наворотами"
@@DmitryAfanasyev Да, это понятно. github.com/Mahmoudz/Porto#Implementations-Projects - там в разделе Implementation есть C#. * - сильно громоздкая описательная часть (имею ввиду ту же систему каталогов (понимание есть, что и ее можно не реализовывать в полном объеме)). В ощм хотелось уже что-то готовое поковырять. Еще раз спасибо.
@@zkhrv.r Привет! Присматриваюсь к Порто, можешь подсказать как дело обстоит с подключением сторонних пакетов, которые заточены под стандартную архитектуру laravel
@@DmitryAfanasyev например, мне нравится для админки использовать github.com/z-song/laravel-admin, при установке пакета в папке app создается папка Admin, где и происходит вся работа с админкой, вот думаю получится ли подружить, в основном пользуюсь шаблоном проектирования "Тонкий контроллер - Толстая модель"))), опыта в построении норм архитектуры нет, и у меня почему-то сразу появился вопрос о удобстве применения сторонних пакетов для laravel, как-будто могут быть сложности с порто.
@@albertgumarov5150мне кажется использование namespace легко решает этот вопрос, единственное если от пакета зависят несколько контейнеров то нужно вынести эту зависимость в слой корабля
Дмитрий, в прошлых роликах ты говорил что нельзя просто так вызывать таски, что они как матрешка и надо их вызывать только из экшона. Но на 20й минуте видно как ты из СерверМанагера просто стучишся в таску. Вызывает сомнения) (понимаю что это может быть просто для примера, объясни пожалуйста) Сейчас как раз переписываю приложение из шаблона "толстые контроллеры" в сервисы/репозитории, и порто заинтересовал. Заодно спасибо тебе за подробное объяснение и с юмором)).
В данном случае менеджер это проводник логики модуля во внешний мир. Соответственно в другом модуле в экшоне или сабЭкшоне может быть вызов данного таска через посредника.
Спасибо! Интересный курс вышел. Получается, что, если не пользоваться Apiato, придётся перелопатить многое из структуры Laravel: app разбить на Ship и Containers, изменив всё, что связано с перенесённым содержимым этих папок; для того, чтобы каждый маршрут был в своём файле, что-то поменять в провайдерах и т.д? И только потом уже появится возможность писать чистый код.
Хочу услышать ваши комментарии по своему способу : Если нам необходимо в контейнере products использовать CategoryTask::getById из контейнера categories, то 1. Необходимо создать интерфейс CategoryContract::getById 2. Указать интерфейс в CategoryTask 3. В провайдере ProductsProvider контейнера products зарегистрироваться интерфейс CategoryContract с реализацией CategoryTask. Так посмотрев провайдер мы всегда будем знать зависимости текущего контейнера. П.С. Идеальный случай если у интерфейса нет зависимости от текущего контейнера то можем поместить его в корабль что позволит в провайдере поменять реализации.
@@DmitryAfanasyev от кого зависит описано в провайдере контейнера А. Кто зависит от контейнера А мы можем ориентироваться только по наличию в нем интерфейсов
Я может невнимательно смотрел видосы и документацию Apiato, но кто нить подскажет куда сводные таблицы пихать?! У меня есть секция MusicSection, контейнеры внутри: Artist, Album, Track, Tag, Playlist. Есть сводные таблицы типа artist_album (Когда альбом может быть у нескольких исполнителей), track_playlist (Когда трек может быть в разных плейлистах). Куда и как оформлять такие таблицы по канонам Porto?! А еще например есть контейнер Country (Страна), может быть вообще у любого контейнера в любой секции - это в Ship Лучше вынести?
Предлагаю заглянуть в базу - "Чистая архитектура" Глава 34, параграф "организация и инкапсуляция". Так же в этой же книге обсуждается и по каким принципам организовывать код в модули. Мартин сразу предостерег что организация модулей которая лежит на поверхности, именно то как ты и описал, может оказаться не верной, но начать можно именно так.
Дмитрий, приветствую. Смотрю я на все эти красивости, что Вы рассказываете.. и грущу) Из моего опыта заказчику совсем неважно применение в проекте паттернов. Лишь бы это работало и было выполнено в установленные сроки, красивенько, "гладенько на JS" - все на что обращает внимание заказчик. При этом на реализацию бэкэнда всем положить) При разработке крупных и сложных проектов и сервисов паттерны может быть и применимы, но для мелких или не сложных проектов, коих подавляющее большинство - как по мне не имеет никакого смысла. Лара по доке (или битрикс) + несколько пакетов + Livewire по сути решают все задачи. И современное поколение веб-разработчиков работает именно так (в лучшем случае). Получается уж очень узкоспециализированная и небольшая ниша о которой Вы рассказываете, или я всеже не прав? Кто эти заказчики для которых это действительно важно? Крупные компании типо Яндекса, гугла и.т.п?
Да эта архитектура или DDD необходима в крупных проектах, сейчас работаю с большим легаси проектом, так чтобы добавить даже небольшой новый функционал иногда приходится несколько дней делить его на классы потому что когда у тебя портянка из 5-20 if...else и ты понимаешь что тебе придется добавить еще иффов то мозг взрывается и отказыватся это обрабатывать.
![Porto: Архитектурный шаблон [ Базовые концепции ] ► Порто №1](http://i.ytimg.com/vi/4V5C3zI_8KI/mqdefault.jpg)
![Porto: Архитектурный шаблон [ Базовые концепции ] ► Порто №1](/img/tr.png)
![Porto: Containers [ Слой Контейнеров ] ► Архитектурный шаблон Порто №3](http://i.ytimg.com/vi/hAjOQFuu-Zk/mqdefault.jpg)
а практика, хочется посмотреть как любой проект перенести).. Запиши плиз как к примеру у тебя же есть blog на ларке перетащить на порто) было бы очень интересно
Большое спасибо за курс!
Дмитрий, благодарю за подробные и интересные объяснения. Как всегда всё доступным языком и по полочкам разложено. Отправил донат, надеюсь он до тебя дошел!))) Очень приятно, когда просьбы услышаны и интересующие темы раскрываются. Блог был очень достойно разобран в чудесном курсе по Laravel, может в этот раз разберём слегка усложнённый интернет магазин? Например про ювилирку, там от размера кольца может меняться торговое предложение. Это было бы интересно посмотреть как логика разложенная с помощью паттерна Porto позволяет использовать сложные структуры данных.
Благодарю!
Донат дошел, спасибо!
Дмитрий, спасибо за твои ролики, всегда смотрю с большим интересом. Вчера у Махмуда вышла 10-я версия Apiato для Laravel 8.
Спасибо за отзыв! Новость отличная, не знал, спасибо.
В Apiato это решено так. Все таски и экшоны вызываются методом call(). Есть артисан команда которая показывает какой контейнер от какого зависит беря во внимание вызовы call(). php artisan apiato:list:dependencies app/Containers/{container-name}
Так а чем это по сути может помочь, от знания зависимостей проект дробится лучше не станет. В конце концов просто окажется, что через череду зависимостей у нас будет божественный контейнер который будет обращаться ко всем или критическому числу тасков в других контейнерах.
Контроль зависимостей. Чтобы вовремя предупредить нарушение архитектурных границ. Полезно когда большая команда и простым ревью нарушение можно пропустить.
@@DmitryAfanasyev Это понятно. Просто выше было написано "в apiato это решено так". То есть либо шла речь исключительно про отслеживание зависимостей либо, как я понял, в общем о сокращение связывания. И архетектурно, на мой взгляд, это никак не помагает сократить связанность. Решение с теме же фасадами выглядит более контролируемым, а в целом, как впрочем и всегда, нужен еще один управляющий слой абстракции.
Как ни странно порто решил большинство проблем со структурой моего кода. До твоего курса пребывал его использовать, но как то не зашло. Сейчас пересмотрев курс, внедряю порто в новый проект. И скажу что очень доволен. Спасибо
Прелесть порто в том что заимствовать можно кусками. Не обязательно "всё и сразу".
Спасибо за труд
Огромное спасибо!!!
Вам спасибо за просмотр 🙏
Ещё один видосик, нормальнааа
Коллеги программисты, доброго времени суток. Вопрос о разделении монолита с архитектурой Porto на микросервисы. Как вынести контейнеры, чтобы они друг о друге ничего не знали, и их взаимодействие настроить через RabbitMQ или Centrifugo? (сейчас у нас на некоторых проектах используется Centrifugo, взаимодействие микросервисов происходит через сокеты).
Каким образом они у тебя о друг друге знают?
@@yashkevich8164 если явно из одного компонента обратиться к другому, тогда знают
@@ДмитрийЖунёв-я7г ну по конкретней то приведите пример) связанность тоже разного рода бывает. может у вас одна база общая к примеру и вы этим там все зхаваязали.
Спасибо за уроки. Лайк, донат, вечная подписка. Жду продолжений других плейлистов.
По подходу Porto возникло несколько вопросов.
1. Если нужно добавить колонку в таблицу и есть два контейнера, для админки и для пользователей, то в какой контейнер класть миграцию? Если в какой то один, то если в будущем выпилить его, то другой контейнер об этом и не узнает.
2. Для фронтэнда при использовании общих лейаутов для вьюх как быть? Выносить на уровень коробля или использовать менеджеры про которые вы упоминали? Посмотрел Апиато, у них для каждого контейнера свой html и стили в базовой архитектуре.
3. И еще про фронтэнд. Стили и скрипты по контейнерам тоже возможно разложить? И не добавлять каждый раз в webpack.mix.js а как-то автоматизировать этот процесс.
Еще раз спасибо за вашу работу.
Развязывать нужно через интерфейсы, внутри секции должна быть большая связность, снаружи слабая
(Low Coupling (низкая связанность) и High Cohesion (высокое зацепление))
Доклады на эту тему
(видео) Сергей Протько "Связать и развязать"
(видео) PHP NN #4: два доклада для поклонников Symfony и сочувствующих с 1:05:00
(статья) Модульный PHP монолит: рецепт приготовления
Все дороги ведут к "Чистая архитектура". Остальное от лукавого 😁
Всем доброго времени суток. Вышла Apiato 10.0.3 она на Laravel 8 и рекомендуется PHP 8.
Советую взглянуть.
Спасибо за видео. Практики бы, мб за 30 минут блог на порто )?
спасибо
пушка-гонка
Как итог сам шаблон порто может быть разбит на микросервисы и быть собранным на этих же микросервисах зависимости коробля правда придется занести в контейнер но это дело уже такое
Скажите пожалуйста, а есть ли реальный пример на худо-бедно большом интрепрайз проекте? Где будет бизнес логика, довольно сложная или с хитрецой, где будет много взаимодействий. вычислений и построений классов и взаимодействий по логике. .. Потому что методы в стиле findUserById, findUserbyEmail - это на столько мелко, что ради такого переделывать обычную структуру совершенно не стОит. Любой CRUD (а это в примерах по сути и есть) любой фреймворк за 5 минут генерирует. А структура ради структуры - ну такое...)) Интересно увидеть реально большой и практический жизненный пример с "наворотами"
Спасибо, Дмитрий. Стабильный лайк. Подскажите а реализацию Порто на C# не встречалась? Может быть есть какие-нибудь ссылочки-наколочки?
Нет, не встречал. Но это же концепция. Можно самому реализовать, при условии что подобный прдзод актуален для С#
@@DmitryAfanasyev Да, это понятно. github.com/Mahmoudz/Porto#Implementations-Projects - там в разделе Implementation есть C#. * - сильно громоздкая описательная часть (имею ввиду ту же систему каталогов (понимание есть, что и ее можно не реализовывать в полном объеме)). В ощм хотелось уже что-то готовое поковырять. Еще раз спасибо.
Спасибо за видео. Было бы интересно пообщаться с ребятами, которые работали/работают с Porto.
Сам работаю с ним уже второй год
@@zkhrv.r Привет! Присматриваюсь к Порто, можешь подсказать как дело обстоит с подключением сторонних пакетов, которые заточены под стандартную архитектуру laravel
Есть примеры таких пакетов?
@@DmitryAfanasyev например, мне нравится для админки использовать github.com/z-song/laravel-admin, при установке пакета в папке app создается папка Admin, где и происходит вся работа с админкой, вот думаю получится ли подружить, в основном пользуюсь шаблоном проектирования "Тонкий контроллер - Толстая модель"))), опыта в построении норм архитектуры нет, и у меня почему-то сразу появился вопрос о удобстве применения сторонних пакетов для laravel, как-будто могут быть сложности с порто.
@@albertgumarov5150мне кажется использование namespace легко решает этот вопрос, единственное если от пакета зависят несколько контейнеров то нужно вынести эту зависимость в слой корабля
Куда пропал бро! без тебя в интернете нет ничего особо полезного по larave! Возвращайся скорее!
Скоро-скоро
Чем то похоже Porto->Manager, на Laravel->ServiceProvider.
Нормальные для таких уровней как по мне два последних варианта. И 2-й больше для библиотечной архитектуры.
Дмитрий, в прошлых роликах ты говорил что нельзя просто так вызывать таски, что они как матрешка и надо их вызывать только из экшона. Но на 20й минуте видно как ты из СерверМанагера просто стучишся в таску. Вызывает сомнения) (понимаю что это может быть просто для примера, объясни пожалуйста)
Сейчас как раз переписываю приложение из шаблона "толстые контроллеры" в сервисы/репозитории, и порто заинтересовал. Заодно спасибо тебе за подробное объяснение и с юмором)).
Укажи плз метки времени. Из приложения студии к сожалению нет перехода к видео...
20:00
В данном случае менеджер это проводник логики модуля во внешний мир. Соответственно в другом модуле в экшоне или сабЭкшоне может быть вызов данного таска через посредника.
@@DmitryAfanasyev пожалуй, понял, спасибо)
Спасибо! Интересный курс вышел. Получается, что, если не пользоваться Apiato, придётся перелопатить многое из структуры Laravel: app разбить на Ship и Containers, изменив всё, что связано с перенесённым содержимым этих папок; для того, чтобы каждый маршрут был в своём файле, что-то поменять в провайдерах и т.д? И только потом уже появится возможность писать чистый код.
Нет, папку апп можно не трогать.
Привет, сколько планируешь по Порто еще выпустить видео?
Я же об этом в видео сказал - это завершающее видео. Если что-то и будет когда-нибудь - то какие-либо дополнения, изменения и тп.
Хочу услышать ваши комментарии по своему способу :
Если нам необходимо в контейнере products использовать CategoryTask::getById из контейнера categories, то
1. Необходимо создать интерфейс CategoryContract::getById
2. Указать интерфейс в CategoryTask
3. В провайдере ProductsProvider контейнера products зарегистрироваться интерфейс CategoryContract с реализацией CategoryTask.
Так посмотрев провайдер мы всегда будем знать зависимости текущего контейнера.
П.С.
Идеальный случай если у интерфейса нет зависимости от текущего контейнера то можем поместить его в корабль что позволит в провайдере поменять реализации.
Классный способ. Но так мы узнаем кто зависит от контейнера А, но от кого зависит он сам не узнаем.
@@DmitryAfanasyev от кого зависит описано в провайдере контейнера А. Кто зависит от контейнера А мы можем ориентироваться только по наличию в нем интерфейсов
Менеджеры похожи на шаблон проектирования Фасад на самом деле. Хотя аналогия с Менеджерами намного понятнее
Я может невнимательно смотрел видосы и документацию Apiato, но кто нить подскажет куда сводные таблицы пихать?!
У меня есть секция MusicSection, контейнеры внутри: Artist, Album, Track, Tag, Playlist. Есть сводные таблицы типа artist_album (Когда альбом может быть у нескольких исполнителей), track_playlist (Когда трек может быть в разных плейлистах). Куда и как оформлять такие таблицы по канонам Porto?!
А еще например есть контейнер Country (Страна), может быть вообще у любого контейнера в любой секции - это в Ship Лучше вынести?
Предлагаю заглянуть в базу - "Чистая архитектура" Глава 34, параграф "организация и инкапсуляция". Так же в этой же книге обсуждается и по каким принципам организовывать код в модули. Мартин сразу предостерег что организация модулей которая лежит на поверхности, именно то как ты и описал, может оказаться не верной, но начать можно именно так.
@@DmitryAfanasyev о, у меня как раз эта книженция есть, но я ее еще не прочитал! Спасибо большое!
Как понять ООП?
Как и любую другую область информации.
Дмитрий, приветствую. Смотрю я на все эти красивости, что Вы рассказываете.. и грущу) Из моего опыта заказчику совсем неважно применение в проекте паттернов. Лишь бы это работало и было выполнено в установленные сроки, красивенько, "гладенько на JS" - все на что обращает внимание заказчик. При этом на реализацию бэкэнда всем положить) При разработке крупных и сложных проектов и сервисов паттерны может быть и применимы, но для мелких или не сложных проектов, коих подавляющее большинство - как по мне не имеет никакого смысла. Лара по доке (или битрикс) + несколько пакетов + Livewire по сути решают все задачи. И современное поколение веб-разработчиков работает именно так (в лучшем случае). Получается уж очень узкоспециализированная и небольшая ниша о которой Вы рассказываете, или я всеже не прав? Кто эти заказчики для которых это действительно важно? Крупные компании типо Яндекса, гугла и.т.п?
Умение писать код от заказчика не зависит.
Написать код - месяц-два, а потом поддерживать его годами нужно будет.
Да эта архитектура или DDD необходима в крупных проектах, сейчас работаю с большим легаси проектом, так чтобы добавить даже небольшой новый функционал иногда приходится несколько дней делить его на классы потому что когда у тебя портянка из 5-20 if...else и ты понимаешь что тебе придется добавить еще иффов то мозг взрывается и отказыватся это обрабатывать.
Спасибо за ролики,
Предлагаю вам рассказать про вот такую архитектуру
github.com/lucidarch/lucid