Вертикальное разделение кода, тестов и конфигов
Спонтанно выступил с докладом и заодно технически организовал трансляцию третьего митапа сообщества BeerPHP SPb. Понял, что проведение трансляции тренирует стрессоустойчивость, так как почти всё, что могло пойти с техникой не так, пошло не так. Но получилось отлично:
Там была пицца с капучино для нас и доклады для вас:
- 00:06:08 - Дмитрий Елисеев: Вертикальное разделение кода, тестов и конфигов
- 00:39:26 - Владимир Закотнев: Поиск SQL инъекций и некоторые способы защиты от них
- 01:05:16 - Сергей Кирьяков: Проектирование сервисов и работа с RabbitMQ
- 01:23:53 - Денис Пенкин: Что надо знать о кэшировании
По мотивам доклада Валентина Удальцова рассказал про используемую мной похожую вертикальную группировку кода проекта по фичам на отдельные модули и компоненты вместо горизонтального разделения по типам классов. Дополнительно рассмотрел, что делать с контроллерами, агрегирующими данные, и как удобнее раскладывать юнит-тесты и конфигурацию в такой структуре.
- Слайды моего доклада
- Митап Нижнего Новгорода про Symfony
- Канал Пых от Валентина Удальцова
- Канал BeerPHP SPb
- Список PHP-сообществ по городам
- Канал сайта ElisDN.ru
- Мои скринкасты проекта с похожей структурой
- Канал скринкастов
На оффлайн пока отвлекаться не буду. Впереди у нас новая статья про инъекции зависимостей в продолжение предыдущей в @elisdnru и вебинар с рецензированием требований ТЗ и новые скринкасты про разработку аукциона и фреймворка в @deworkerpro.
Александр КропотовВопрос. USE .. между классами, размещенными в разных, вертикально разделенных модулях:
а) не допускаются категорически
б) можно использовать как угодно
в) определяем интерфейсы где-то (где?) и работаем только через интерфейсы?
Так то да, красиво по модулям разложить, гораздо проще найти что где, но с точки зрения связанности кода никаких гарантий независимости автоматически, только из за изменения структуры src, не получится же.
Дмитрий ЕлисеевЕсли такое понадобится, то для слабой связанности лучше делать через интерфейсы.
Но лучше переделать код и/или перекомпоновать модули так, чтобы таких связей не было.
Дмитрий АлексеевДля отслеживания зависимостей внутри слоев модуля или между модулями есть утилита под названием deptrac. https://github.com/qossmic/deptrac
Дмитрий ЕлисеевДа, про неё рассказано в докладе Валентина Удальцова.
МаксимПравильно ли я понял, если у меня есть ведущий, который проводит разные мероприятия: премии, соревнования и т д, то это вполне логичный модуль «проведения мероприятий»? Так же есть отдел, который занимается регистрацией на все эти типы мероприятий, то у него тоже будет свой контекст:
Registration/Registrator
Registration/Awards
Registration/Competition
Регистрация это, как правило, стойка на мероприятии для регистрации или подтверждения регистрации и выдача всей документации, а так же его оплата, если мероприятие платное. После регистрации уже участник попадает в программу к ведущему и в экспертизу на оценку или голосование.
Поясните ещё почему profile является отдельным модулем? Разве профтль это не часть какого-то модуля? Например, в наградах один профиль, в организаторах другой. Или что-то не так понимаю? Или как тогда быть с разными профилями? Организатора, участника, специалиста и т д.
Не очень понятно как модуль станет независимым, если он ссылается по id то на локацию, то на организатора, то на ещё что-то. Получается насовсем зависимый. Много зависимостей может быть, но только они слабые зависимости. Такие зависимости допустимы, получается?
Дмитрий Елисеев> Не очень понятно как модуль станет независимым, если он ссылается по id то на локацию, то на организатора, то на ещё что-то.
Модуль или объект является независимым, если в коде не вызывает никакие чужие модули или объекты. Тогда можно взять его код и вынести в отдельное приложение-сервис со своим API и своей БД.
А хранение копий значений вроде id локации как раз такой прямой зависимости не имеет. Можно спокойно запускать такой модуль без запуска оригинального модуля локации.
Дмитрий Елисеев> Поясните ещё почему profile является отдельным модулем? Разве профиль это не часть какого-то модуля? Например, в наградах один профиль, в организаторах другой.
Про это я и говорил в комментариях в YouTube на примере юзера, что нужно все данные раскладывать по своим местам. В Profile можно оставить только нейтральные данные вроде имени и фотографии. Или даже чтобы не было путаницы можно переименовать Profile в People. А те данные, которые касаются каждого конкретного модуля, уже нужно помещать в свои сущности-профили в каждом модуле.
Дмитрий Елисеев> Правильно ли я понял...
Попробуйте поэкспериментировать и нарисовать разные варианты. Вы этот проект с начала уже делаете два с половиной года, так что уже подробно знаете, что и как происходит внутри.
МаксимВот как раз и хочу сделать всё академично) Это у меня такой тренировочный проект, на котором применяю ваши практики) Переписываю, дополняю, изменяю)
Иван Лещёвне знаю кому как, а для меня горизонтальный/вертикальный контринтуитивно как-то
прям совсем совсем надо напрягаться, чтоб понять, кто сейчас горизонтальный, а кто вертикальный
группировка по слоям vs по фичам куда как понятнее
Дмитрий Елисеев> группировка по слоям vs по фичам куда как понятнее
Так и есть. По горизонтальным слоям или вертикально по фичам.
Иван Лещёврежем вертикальными линиями то, что на одном уровне или режем то, что на одной вертикали?
и наоборот, режем то, что на одной горизонтали, или режем горизонтальными линиями?
в общем, терминология не самоочевидна
Vladimir PerepechenkoДа, послушать бы такой доклад полгода назад. А то уже раза четыре переделывал структуру.
Я уже сделал себе так:
модули и, соответственно, корневые папки:
App\Driver - всё про водителя, но не более. Независим.
App\PaymentProvider- те, кто осуществляет денежные переводы, но не более. Независим.
И тут я вспоминаю, что бизнес занимается платежами для водителей.
и делаю
App\DriverPayment, который использует два вышестоящих модуля.
И \Driver и \PaymentProvider могут использоватся и будущими модулями. Хотя сами по себе они мало-полезны.
В дальнейшем планировал добавлять модули такми же образом:
Например, добаваляем бизнес-область "Аренда авто" для водителей той же лавки - App\CarRent, который будет использовать уже имеющийся App\Driver.
Можете пояснить, что потенциально плохого в такой структуре? Вроде как App\DriverPayment по своей природе не может быть независимым, так как объединяет две области деятельности?
Николай Романов – site2go.ruэх, жаль трансляция больше недоступна
Дмитрий ЕлисеевВ каком смысле недоступна?
Николай Романов – site2go.ruвот https://s.mail.ru/BNZz/JT7FVSvut
Дмитрий ЕлисеевУ меня всё доступно и из инкогнито.
ОльгаИ у меня все доступно
Валерий ФедоровУ меня также всё открылось и работает. Спасибо за всю информацию предоставленную. Я немного разбирался сам, но самообразование - это хорошо и не всегда достаточно. Хочу пройти курсы в школе XYZ, чтобы научиться программировать игры https://www.school-xyz.com/code-professions . Это моя давняя и пока нереализованная мечта. Вторая профессия никогда не помешает и ещё - это очень интересно.
Иван СавельевНа самом деле полезная информация и я люблю такие информативные статьи и рекомендации читать. Кто бы мне ещё подсказал по Фигме хорошее обучение. Вижу что курсы есть разные https://skillsit.ru/dizajn/kursy-figma/ но хочется выбрать реально те, которые дадут максимально прочную теоретическую базу....