Ахахахх, первый же скрин с доменной моделью нарушил все законы - видно парни просто долго с нестом разбирались, до ддд "руки пока не дошли")) И это не "допущения" - это НАРУШЕНИЕ, и так делать не нужно))) Выделять модели бизнесовые нужно отдельно, выделять модели связанные с БД отдельно ------------------------ Очень жаль что ничего не было сказано про междоменное общение( ------------------------ TableFromModel - сомнительно, нооооо, не окей....... ------------------------ Цикличные зависимости зачастую тебе кричат - у тебя проблемы в архитектуре
Фасады это не статика, а синтаксический сахар, не хочешь фасады, не используй. Если уж говорить о связанности с фреймворком, то это в первую очередь active record и eloquent. Откуда столько тревоги о связанности с фреймворком? Хоть раз доводилось в существующем проекте менять фреймворк?
@@andreyvoskresenskiy2284 Корош сахар, когда по итогу у тебя все на все завязано, поправил в одном месте, "отъехало" в "двух других", ведь эти фасады начинают лепить везде, вдохновившись подходом в ларке. А если еще тестов нет, ващпе песня!)). Синтаксический сахар это стрелочные функции или null-коалесцентный оператор и тп, а фасад это паттерн. С фасадами нужно быть аккуртатным их сам применяю только там, где нужно скрыть логику компонента системы за понятным интерфейсом, а если херачить на все фасады до жди беды, собено если придется рефакторить потом это дерьмо и особенно если нет тестов... Есть вообще ощущение что фасады ларавельщиками воспринимаются как серебрянная пуля, особенно у джунов и мидлов, тех кто не выхватил от этого еще проблем - незнаешь что делать, нужно зафигачить фасад) По поводу смены фреймворка (собственно даже видос про это) есть такой опыт, как раз из за hight cohesion испытывали страдание и боль от неправильных решений принятых разрабами ранее. Кароче удачи с фасадами! 😉
на мой личный взгляд YII2 уже всё, хлам. Сейчас рулит Ларка, даже Симфони уже хлам, Ларка на голову выше всех, это касается и документации, и комьюнити и сахаром кода, разрабатывать на ларке одно удовольствие (лично моё мнение) Правильно сделали что перешли на ларку !
@@evgeny_5891 не смущает, посмейся, особенно с документации симфони, я с неё тоже ржу.. и ржу с того как ларка обходит кратно по популярности и лаконичности симфони. За ларкой будущее однозначно, симфони в скором будущем будет на задворках валяться, можешь потом зайти через пару лет и перечитать мой коммент, посмеяться ))
А почему в Домене лежит модель со ссылкой на деталь (орм) это же нарушает суть CA. Ее как раз нужно выносить в infra. И там через interface внедрять в adapters
Основной вопрос : зачем? Остался без ответа. И ответ: 1.просто чтобы тупо подсадить на себя клиента, 2. не разбираться в битриксе. Таким образом получаем манипуляцию.
Зачем: 1. В тендерах и документации заказчика может быть указан сразу Битрикс. Ты можешь конечно не лезть в тендеры - но упустишь свой кусок рынка крупных контрактов. Т.к. почти все большие корпорации борются с коррупцией тендерами. 2. Битрикс как api based cms + framework = одно из лучших решений на рынке PHP. Ближайшая альтернатива Drupal + symfony. Менее удачная: october + laravel. Знаете другие варианты предложите. 3. Вариант с framework + custom админка = сразу +30% трудозатрат бекенда 4. Битрикс содержит в себе сразу определенный набор бизнес логики и интеграций. Которые в голых фреймверках зачастую допиливать с нуля. Писать интернет магазин с нуля на фреймверке (даже на их поделках) кажется очень глупой затеей в России.
@@north-leshiy, интересно ты CMS с фреймворками сравнил, совсем о разном) Я работал с битриксом 2 года и очень страдал от их готового функционала, т.к кастомизировать его сложно и проще свой написать. Последние пол года переехал на laravel и очень рад, как глоток свежего воздуха. Битрикс хорош в том, когда нужно быстро развернуть стандартный информационный сайтец, просто натянув верстку. Шаг влево и сталкиваешься с ограничениями компонентов и начинаются страдания, ТП тупит, куча багов и сидишь в панике. Как пример, компонент поиска, я как-то столкнулся с тем, что мне нужно искать элементы, у которых цена больше 0 и в настройках компонента этого нет, а в коде там миллиард непонятного кода вперемешку с js, html, css и php. На фреймворке это делается 5 минут, просто формируя запрос в бд. Взять комплексный компонент например catalog, да там вздернуться можно. В каком-то из компонентов видел комментарий, к которому цепляется JS! Это из коробки... Модули других разработчиков тоже боль, много из маркетплейса которые не работают, не поддерживаются. Нужно какое-то поле добавить в него, снова боль
что за сексизм по отношению к мужчинам? Думаете приложения для беременных разрабатывают только девушки. Именно девушки, не женщины. Которые еще не родили
Круто, выглядит все супер, но у меня вопрос, а что делать людям с мониторами реально большими? Во первых если больше 1920, то уже в принципе неудобно водить головой по сторонам чтобы воспринимать весь крутой широкоформатный контент. А про Маки вообще молчу, как будто дорогу перехожу: "Посмотрите сначала налево, потом направо. Ой, вы уже забыли что было слева? посмотрите еще раз"
Зачем такой треш выкладывать? Мало того, что всю дорогу смотрим на чью-то плешь, так с 12 минуты еще и звук пропадает. Из выводов... если взять тильду и накидать в нее кучу платных костылей типа "бесплатного" oprosso (стартует с 100тр в год), то после долгих танцев с бубнами получим аналог магазина на средненькой cms. Бррред. Тильда хороший конструктор, но не надо в него впихивать невпихуемое.
мне понравилось что рассказали о фильтре старого образца сначала, а потом показали улучшенный. Помогает понять что это шаг в перёд, инновация, а не просто деньги освоить.