Вертикальное разделение кода, тестов и конфигов

Спонтанно выступил с докладом и заодно технически организовал трансляцию третьего митапа сообщества BeerPHP SPb. Понял, что проведение трансляции тренирует стрессоустойчивость, так как почти всё, что могло пойти с техникой не так, пошло не так. Но получилось отлично:

Открыть в YouTube

Там была пицца с капучино для нас и доклады для вас:

  • 00:06:08 - Дмитрий Елисеев: Вертикальное разделение кода, тестов и конфигов
  • 00:39:26 - Владимир Закотнев: Поиск SQL инъекций и некоторые способы защиты от них
  • 01:05:16 - Сергей Кирьяков: Проектирование сервисов и работа с RabbitMQ
  • 01:23:53 - Денис Пенкин: Что надо знать о кэшировании

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



На оффлайн пока отвлекаться не буду. Впереди у нас новая статья про инъекции зависимостей в продолжение предыдущей в @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 по своей природе не может быть независимым, так как объединяет две области деятельности?

Ответить

 

Дмитрий Елисеев

В каком смысле недоступна?

Ответить

 

Дмитрий Елисеев

У меня всё доступно и из инкогнито.

Ответить

 

Ольга

И у меня все доступно

Ответить

 

Валерий Федоров

У меня также всё открылось и работает. Спасибо за всю информацию предоставленную. Я немного разбирался сам, но самообразование - это хорошо и не всегда достаточно. Хочу пройти курсы в школе XYZ, чтобы научиться программировать игры https://www.school-xyz.com/code-professions . Это моя давняя и пока нереализованная мечта. Вторая профессия никогда не помешает и ещё - это очень интересно.

Ответить

Оставить комментарий

Войти | Завести аккаунт | Войти через


(никто не увидит)





Можно использовать теги <p> <ul> <li> <b> <i> <a> <pre>