Видео

можно фильтрацию просто через цепочку обязанностей сделать, а можно еще через декорацию. У каждого варианта свои +/-

В комментариях вы говорите, что выбирая Laravel, надо быть готовым к компромисам. Отсюда делаю выводы, что сложные проекты делать на Laravel нецелесообразно. Тогда зачем выдумывать велосипед, если уже есть архитектура от разработчиков фреймворка? Как минимум, не будет страданий при поддержке. Наверное можно сделать велосипед в пакете. Туда никто не полезет.

Спасибо за видео! Очень доступно рассказываете! Хотелось бы узнать как именно реализованы очереди в laravel, т.е. что под капотом) Новое видео в рубрику "Для тех, кто не знал "))

Спасибо тебе огромное!

Когда добавляю нижний 2 строки куда сказано, выдаёт ошибка про отсуствия модели: Model::preventLazyLoadding(!app()->isProduction()); Model::preventSilentlyDiscardingAttributes(!app()->isProduction());

Недрочибельно.

Спасибо, очень познавательно) вроде простые вещи, а вот запомнить реализацию полезно)

Я к такому же пришёл в итоге, только да, как и ниже кто-то писал у меня всё приложение зависит от папки с контрактами. И обмазал это php insight + deptrac Но тут стучится проблема Eloquent. Чтобы изолировать модели базы данных от слоя управления мы их очевидно вешаем на интерфейсы А так как в пыхе нет интерфейсов на публичные свойства, приходится либо костылями (контракт магического геттера + phpDoc), либо гет методами лечить проблему. В первом случае мы открываем знания о то что можно записать в поле модели в слое управления, что запрещено архитектурно Во втором случае мы ломаем архитектурную концепцию eloquent и начинаем делать чуждые ей геттеры Плюс в системе с единой моделью базы данных очень быстро ключевые модели обрастут деталями других модулей То есть мы сразу ставим правило что модели должны быть анемичными(иначе теряется смысл модульности), а вся логика уйдёт в севисы доменного слоя. И тут ещё приходит проблема, что есть слой модуля, а есть доменный слой и они имеют разное предназначение. Слой модуля - это слой управления доменом. У этого слоя свои сервисы и свои модели(дто) Доменный же слой ультратонкий в котором всё что есть это модели(не eloquent, а в отдельных случаях большого домена - кастомные, которые не зависят от бд) и сервисы Единственная зависимость домена - контракты и модель eloquent. Но мы так же можем архитектурно убрать проблему сохранения моделей не в том месте и создание странных ситуаций тем, что повесим зависимость домена на разбитый контракт модели на write и read-интерфейсы. В общем, та модульность которую ты показал это лишь малая часть огромной работы которую нужно провести для борьбы с хаосом завимостей и нарушения ответственности слоёв. И то не факт что это поймут в боевом проекте. Я такое экспереентирую только в пет проектах. Потому что у меня есть печальный опыт когда боевой проект, написанный с нуля, через полтора года закрылся от крайне высоких затрат на поддержку оверинжиниринга так как никто кроме архитектора не понял написанного и поломал быстро проект до неподдерживаемого состояния.

Дамы и Господа! Коллеги! Поделитесь кто как ставит обновления PHP у себя на компах для разработки и на серверах? Под Windows есть все компилированные сборки... под линух в репах обычно старое и не часто обновляется или вообще не обновляется... Интересует компиляция PHP 8.3 под Astra Linux 1.7... Не спрашивайте почему... Импортозамещение... Есть возможность использовать только из репов 8.1.12 или собрать самому... но без бубна не получается... не спец я в сборках на Си... Кто посоветует статьи, советы или поделится своим опытом в этом вопросе? боюсь остаться на 8.1 вечно...

Вот отлично что сказали что сами особо ими не пользуетесь! И это хорошо, потому что человек изучающий laravel еще не понимает распространенная ли эта практика и надо обязательно юзать это, или просто что есть возможность. Мне просто по началу показалось что это круто создавать свои директивы, но тоже пока толком не было особой нужды. Пока не понравилось что директива не может принять несколько параметров как обычная функция, и надо explode применять, а также охото передать параметры строки в кавычках как в обычную функцию, а они и принимаются с этими же кавычками, как в примере вы вывели имя в кавычках) И даже не сказали об этом)

Спасибо! Всегда интересно!

👍

благодарю

полезно, спасибо

Спасибо за урок! Подскажите, могу попросить поделиться ссылкой на урок, где вы работаете с коллекциями, чтобы не перегружать фронтенд?

❤

сделаешь мини курс чисто по DDD чтобы можно было руку набить?

8:45 @CSRF не защищает от потока спама вообще. За всю сессию он одинаковый. Он защищаем от внешней самой примитивной отправки, но никак не от потока одинаковых комментариев. ну ладно, на 10:40 исправился ))

Приятно смотреть такие рубрики, а ещё когда тесты адекватно работают, мало кто пишет код и ещё показывает его покрытым тестами, спасибо Данил :)

Друг, ну разбираешься ты в Ларке, учишь нас, как разрабатывать на ней - прекрасно, ты хорош в своей нише! Но не лезь в WP, если ровно ничего о нем не знаешь. Даже два года назад, когда ты это записывал, WP был уже сильно больше, чем просто "CMS для бложиков". На нем и 5, и более лет назад строилась серьезная бизнес логика и хорошо масштабируемые системы, а не только простенькие сайты, и чем дальше, тем круче, быстрее, удобней и больше. И я, как опытный WP разработчик, так же легко могу скать: "за-то на WP мо;но разработать всё от маленького лендинга до огромного мгазина и какой угодно сложной системы, или даже сначала сделать клиенту лендинг, который позже играбчи расширить до полноценного сайта и кучей фич, потом добавить туда магазин, по мере роста бизнеса расширить и усложнить его, а потом вообще превратить сайт в самолет, если клиент того захочет, т.е. разработать вообще что угодно и как угодно масштабировать в дальнейшем, а на ларке никто даже и не подумает делать просто легдинг или простенкий сайт, хотя это, конечно же, возможно. Просто на WP функции CMS, не нужные проекту очень просто частично либо полностью отключаются/скрываются, а вот на ларку полноценно прикрутить функции CMS уже не так просто", но не буду, поскольку осознаю, что я не настолько компетентен во фреймворке, и наверняка в чем-то, если не во всем, ошибусь.

Да, наглядность получившегося кода - хуже, чем foreach, согласен. Но я просто обожаю такие красивые лаконичные решения :) Боюсь что не смогу удержаться от использования Пайплайна. Спасибо брат ты красавчик! Лучи добра тебе

Дык это же паттерн Chain of Responsibility (Цепочка обязанностей) походу! На рефакторинг.гуру есть пример. А так то спасибо за краткое хорошее овервью

Отличное видео, спасибо!

Как можна сделать чтоб когда создаю запись через formpage обработкой и сохранение можна было обработать через свой контролер.

Очень прошу, запиши такой ролик!

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

Выглядит как-будто бы просто вы одним доменом завязываетесь на фасад другого домена

очень полезная рубрика!!!

3:03 имеют ли смысл эти интерфейсы в отрыве от соответствующего модуля? 4:15 "взаимодействуем исключительно с помощью интерфейса и публичных методов что нам доступны" 8:17 А как же open/closed? Мы оставляем публичный метод которым нельзя пользоваться и старший разраб должен это контролировать?

немного запутался, но выглядит круто!

спасибо за видос

странный подход, но чем-то интересный. а почему в данном случае интерфейс отделен (namespace) от реализации? в чем преимущество?

Спасибо за урок, как всегда на высоте) до этого работать с полнотекстовым поиском только через SOLR, теперь буду знать ещё и Scout)

6:08 - интересно, но мне кажется это сложнее, чем приучить себя регулярно делать гимнастику. Особенно когда на работе есть живой тестировщик

Даешь приложение в рамках концепкии!

давай ролик по модулям,

По больше всего этого

Классный ролик! Очень полезный материал!👍

Вы просто супер жду ролик про тесты.

Ждем следующие видео на эту тему. С примерами и так далее

Спасибо за ролик! Подход с коммуникаторами очень похож на подход API + Adapter в чистой (слоеной) архитектуре Было бы очень интересно посмотреть пример проекта с изолированными модулями

Ролик в студию. Ты просто мастер объяснять. Постоянно смотрю даже то, что знаю!😂

Пачка стабильных коммуникаторов в одном пакете делает этот пакет не стабильным)) Мне кажется минимум-стабилити слишком серьезно будут меняться при небольших изменениях в старом модуле после добавления новых. По сути: был у тебя 1.0.1 с User и Subscriptions интерфейсами. Далее обновили 1.1.0, 1.2.0 ... и т.д., а потом понадобилось добавить в User ещё метод, который нужен для Subscription и мы уже минимум-стабилити версию со старой доброй 1.1.0 в Subscriptions поднимаем резко до 1.51.1 и там всплывает куча розеток для других модулей, поморщатся даже самые невозмутимые разрабы 😄 Лучше такие коммуникаторы делить на отдельные пакеты. Нужно например для Users использовать Subscriptions и Payments, подключаешь нужные коммуникаторы без лишних интерфейсов. А вообще проще в нужном модуле создать нужные интерфейсы (как розетка наружу модуля) и адаптировать модули на их общем уровне (адаптерами с реализациями интерфейсов). А если начинают дублипроваться в модулях, то уже можно и как отдельный коммуникатор модуля вынести. (Вот сейчас немного сам запутался с направлениями связей, но суть в том чтобы не плодить пакеты интерфейсов если можно через такие связывать модули на уровне инфраструктуры и создавать отдельно на модуль, если нужны в других пакетах непосредственно)

Полписался. Да сними пожалуйста развернутый ролик о TDD

Ждём ролик про тесты!)

Почему у тебя User.php лежит внутри модуля? Это не правильно если он используется контрактом то он должен лежать рядом с контрактами

имхо, неудачное название комуникатор. может быть Connector, Bridge, или даже просто ...Module

Классный материал, будут интересны и другие видое в этом направлении

Большое спасибо!