Еще бы тесты напихать, как Дмитий показывал в докладе и вообще норм. Правда надо тогда все пути в phpunit указывать что не удобно будет

так обычно тоже не получается, редко бывают фичи в вакууме

Ну на фронте так получается у меня

На беке просто пока руки не доходят так попробовать

Ибо проекты обычно не настолько большие чтобы это имело смысл

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

Что-то значит не то с архитектурой

Ну не поверю что все фичи зависят друг от друга

И нельзя что-то удалить чтобы другое все не сломалось

Кешер да знает о многом, но это не обязательно что все другое должно знать про кешер

не, кешер как раз пофиг, ему дали строку ключа и какие-то данные, ну метадату навроде тэгов-ттлей

Ну не поверю что все фичи зависят друг от друга

Даже если не будут зависит прямо будут зависеть косвенно: генерить какой то ивент, или быть источником инфы для другой фичи и т.д. Понятно что не все фичи так зависят, и есть полностью изолированные, но таких мало, имхо. Система мб и не грохнется с 500, но встанет.

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

оно все на бумаге только отчуждаемо, а в жизни бизнес не будет слушать "мы не можем сделать автоматические рассылки по распродажам потому что это смешение предметных областей" или "нам надо пересмотреть границы наших контекстов"

по-хорошему это все на микросервисы надо дробить, но с 5 рпс нагрузки и пятью разрабами, это не очень умно

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

Ну кстати тут контекст интересный. Нпаример удаляем расчет цен. Значит пушей не будет, - нет ивентов (не ломается значит просто отключается). Отчет - тут хз, упадем по базе, убрали фичу - нет базы. Хотя если отчет куда то там ходил асинхронно, то ему эти данные никто не заполнит, будут 0 , отчет не упал. Топ юзеров та же история, просто фича не дает свои сайд эффекты

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

как условно если бы это был фронтенд: допустим есть какой-то виджет (календарик там), он перестал быть нужен, его удалили из единственного места, что его импортил, удалили папку - и живем

на сервере так уже сложнее

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

Не "ну ок", расчет цен как то остался после удаления, это однозначно не получится 😅😅😅

на сервере так уже сложнее

Вот это самое основное, и профита в этом будет несоизмеримо меньше чем трудов

Простите... я думал только у нас "ювелирные работы на боевом сервере") или это в принципе не редкость?

или я неправильно понял обсуждение про сервер?)

Хз опять таки все это признак tight coupling

Простите... я думал только у нас "ювелирные работы на боевом сервере") или это в принципе не редкость?

Ну я лично вас не понял :) Мы обсуждаем возможность удаление папки фичи, без дальнейшего дополивания остального кода, при котором сервер и остальной функционал останутся рабочими

Ну я лично вас не понял :) Мы обсуждаем возможность удаление папки фичи, без дальнейшего дополивания остального кода, при котором сервер и остальной функционал останутся рабочими

А, всё норм) это у меня профдеформация) это я не туда подумал.

Расчет цен тут я ничего не понимаю что это такое и почему его нельзя сделать сервисом, который млжно удалить и ничего не сломатется

Хз опять таки все это признак tight coupling

предметная область не всегда loose любит, это все у инфоцыган вроде елисеева ладно складывается

Расчет цен тут я ничего не понимаю что это такое и почему его нельзя сделать сервисом, который млжно удалить и ничего не сломатется

я ж говорю - там десяток входящих связей в этот сервис, понятно что это условно один класс и пяток хелперов

Расчет цен тут я ничего не понимаю что это такое и почему его нельзя сделать сервисом, который млжно удалить и ничего не сломатется

Ну например мы удаляем модуль цен, значит удалили сами цены даже колонки из базы. Мы все же говорим не про калькулятор. Упали сервисы которые работали по join для составления отчетов, где были цены - ну это для примера. Упали сервисы которые спрашивали этот сервис о цене товара например. Ну если мы реально прям круто не заморочились. И опять таки мороки даже если и были, то были для других целей, и даже они мб не переживут "удаление папки".

ну типа того, мы об одном говорим

Т.е. например для низкой связи, нужно послать какой то хук/сообщение, который подхватят остальные фичи и заполнят и уже он вернетя в модуль отчета, и то возможно им не хватит инфы, надо сходить еще куда то, это касается множественных фильтров. Короче надо много чего допилить ради "удаления папки". На фронте же как я вижу: мы удалили какую то форму, остальные формы остлаись рабочими. Там вроде и ненамутишь высокий каплинг при всем желании) В принципе и мы можем на бэке удалить темплейт, а остальные темплейты останутся живыми. А вот если на фронте например удалить фичу "Рендеринг ошибок на форме" или "модуль всплывающего сообщения", будет интересно как фронт переживет это и его импорты ) Хотя я мало за фронт шарю.

на фронте что хорошо - есть компайл-тайм, там тебе скажут что ты импортируешь несуществующее

на фронте что хорошо - есть компайл-тайм, там тебе скажут что ты импортируешь несуществующее

ну на пыхе стат анализ есть

хотя и тесты покажут если грохнутся😅😅😅

ну в том смысле что тут это опциональное, а там никуда не денешься от компиляции)

ну в том смысле что тут это опциональное, а там никуда не денешься от компиляции)

читеры)

Ну например мы удаляем модуль цен, значит удалили сами цены даже колонки из базы. Мы все же говорим не про калькулятор. Упали сервисы которые работали по join для составления отчетов, где были цены - ну это для примера. Упали сервисы которые спрашивали этот сервис о цене товара например. Ну если мы реально прям круто не заморочились. И опять таки мороки даже если и были, то были для других целей, и даже они мб не переживут "удаление папки".

Ну такое. Это вопрос зависимостей модулей и все такое. Никто этим не заморачивается просто

Все пишут 50 контроллеров в одну папку и домой

Ну такое. Это вопрос зависимостей модулей и все такое. Никто этим не заморачивается просто

Заморачиваются если это нужно, а нужно это не для удаления папки. Т.е. для удаления все равно другие требования будут

Все пишут 50 контроллеров в одну папку и домой

лучше-то от 10 папок не станет, если функционал все равно перемешан :) это как если руки из неоттуда, вместо микросервисов получается distributed monolith

Если каждую фичу организовать в бандл, все возможно разнести в разные папки бандлы

лучше-то от 10 папок не станет, если функционал все равно перемешан :) это как если руки из неоттуда, вместо микросервисов получается distributed monolith

А как связыны кривые руки, распределенный монолит, микросервисы?)

Если каждую фичу организовать в бандл, все возможно разнести в разные папки бандлы

И что это даст? Бандлы можно связать. Бандлы зависят от чего то, бандлы должны как то общаться

Слово бандл - ровно ничего дает тут

И тогда твой бандл отчётов будет зависеть от бандла цен и в вроде норм

А как связыны кривые руки, распределенный монолит, микросервисы?)

ну бывает не особо опытная команда решает сделать по-модному и срочно все переписать на микросервисы. но ввиду недостатка опыта (и необходимости), вместо красивой слабосвязанной микросервисной архитектуры получается этот самый распределенный монолит, который имеет недостатки обоих подходов, но не имеет их преимуществ

И тогда твой бандл отчётов будет зависеть от бандла цен и в вроде норм

не, еще хуже. появляется граница, нужно согласовывать форматы общения (поля в дтошках, которыми бандлы обмениваются), писать кучу инфраструктурного кода чтобы настроить эти бандлы

ну бывает не особо опытная команда решает сделать по-модному и срочно все переписать на микросервисы. но ввиду недостатка опыта (и необходимости), вместо красивой слабосвязанной микросервисной архитектуры получается этот самый распределенный монолит, который имеет недостатки обоих подходов, но не имеет их преимуществ

Ммм понял, спасибо. Перепутал модульный/распределенный монолит

Модульный монолит

Модульный монолит

Разнесение на бандлы, папки по фичам - не делает проект хорошим модульным монолитом

Остается все равно много вопросов в декомпозиции и организации

И вообще ясен пень что при удалении допустим модуля цен сломается модуль отчётов. Но поверь, при таклм подходе ты быстро понимаешь какой модуль сломался, и дальше ты уже можешь решить, имеет ди смысл модуль отчётов без модуля цен, если имеет то правишь его, если не имеет то удаляешь его. Это очень легко сделать когда структура папрк отражает функциональные логические единицы, а не абстрактные контроллеры

Попробуйте удалить какой то вендорный бандл, посмотрите что станет с вашей системой)

Самый сложный вопрос - это обещние и передача инфы между модулями, который никак не решается простым "положили в разные папки". Чтобы при этом не связать эти модули и сделать их слабосвязанными

Всем привет👏 Ищу технаря, который может поднять сервак, умеет работать с кейтаро, клоакой, умеет делать интеграции, писать ленды с 0 и копировать/выкачивать существующие🚀 Аутсорс, можем поработать как от 1 проекта так и на долгосрок🤘🏿 Пиши в лс

Самый сложный вопрос - это обещние и передача инфы между модулями, который никак не решается простым "положили в разные папки". Чтобы при этом не связать эти модули и сделать их слабосвязанными

Если так подумать, то вся симфа это есть куча модулей которые как-то общаются друг с другом

Если так подумать, то вся симфа это есть куча модулей которые как-то общаются друг с другом

Да почти никак они не общаются

Есть такая штука как anticoruption layer, чтобы ограничить взаимодействия между модулями

Есть такая штука как anticoruption layer, чтобы ограничить взаимодействия между модулями

Это обычный DIP так если посмотреть. Только при этом один модуль знает о другом так или иначе через адаптер, и один модуль не может существовать без другого, даже если не знает о его адаптере

Работал в прошлой компании, возможности симфони использовались на 30 процентов примерно. Не было такой жёсткой зависимости от фрейма, никаких бандлов

Общайтесь через теги, ивенты, интерфейсы и т.д. и т.д.

Это обычный DIP так если посмотреть. Только при этом один модуль знает о другом так или иначе через адаптер, и один модуль не может существовать без другого, даже если не знает о его адаптере

Ивенты для этого ещё есть

Но вообще обычно среднестатистическому проекту все это не нужно

Общайтесь через теги, ивенты, интерфейсы и т.д. и т.д.

Если я удалю адаптер реализуюзий интерефейс, мы что не упадем? Упадем. Вот как видите ничего не решается в вашей задаче с попомщью anticoruption layer и DIP

Ивенты для этого ещё есть

Это да. Делать отчеты на ивентах вери изи) сарказм

Если я удалю адаптер реализуюзий интерефейс, мы что не упадем? Упадем. Вот как видите ничего не решается в вашей задаче с попомщью anticoruption layer и DIP

Оно решает немного другую проблему

Я же говорю обычно проекты слишком простые, чтобы ощутить выгоду от разбивания на функциональные компоненты

Потому что если у тебя 90% кода зависит друг от друга значит это простл один большой компонент )

Потому что если у тебя 90% кода зависит друг от друга значит это простл один большой компонент )

Да, это прям хорошая мысль

Потому что если у тебя 90% кода зависит друг от друга значит это простл один большой компонент )

Компонент - это модуль или я неправильно понял?

Это кусок проекта который можно удалить

Так чтобы проект прододжил работать и имел смысл

Так чтобы проект прододжил работать и имел смысл

Ну тогда это должен реально маловажный компонент, который зачастую можно удалить и без вот этого вот всего, что мы тут развели )

Это кусок проекта который можно удалить

Я не совсем понимаю, почему нужно рассматривать этот момент с точки зрения удаления, а не изменения

Хотя зачастую все равно DI фрейма слетит и надо что-то менять

Так чтобы проект прододжил работать и имел смысл

Например удаление модуля скидок имеет неравнозначное значение по сравнению с модулем заказов.

Даже если все четко написать и проект не выдавал 500, одно можно удалить и продолжить работать а второе нет, как ни пиши)

Это кусок проекта который можно удалить

Это реально возможно только в контексте фронтовых компонентов

Это реально возможно только в контексте фронтовых компонентов

Ну мелкие вещи можно и на бэке. Удалив модуль нотификации, мы уроним проект? Нет. Удалив модуль акций мы уроним проект? Нет, если напишем +- ровно и поставими себе такую задачу

Ну мелкие вещи можно и на бэке. Удалив модуль нотификации, мы уроним проект? Нет. Удалив модуль акций мы уроним проект? Нет, если напишем +- ровно и поставими себе такую задачу

Тут зависит от размера проекта