jaxel

Что умеет настоящий senior/lead developer кроме знания какого-то языка и его фреймворков?

Что бы вы ни изучали, вы выйдете из вуза джуниором. Сеньорами становятся не выучив синтаксис 10 языков программирования, а сделав 10 крупных проектов. Как и на чём они сделаны не так важно, главное - это те уроки, которые разработчик с них вынес.

Чему стоит научиться за первые курсы для того чтобы повысить свою "цену" как разработчика в будущем?

Исходя из написанного выше: изучите "какой-то язык и его фреймворки" на высоком уровне, чтобы сразу при устройстве на работу начать приносить пользу и получать опыт реализации проектов, а не борьбы с компилятором java. Изучите свою IDE, используйте её эффективно. Ну и посматривайте в смежные области, чтобы расширять кругозор: графический дизайн, UX, другие парадигмы программирования.

Прости что лезу не в свое дело, но мое мнение, что yii2 лучше вообще не изучать. Изучай Laravel/Symphony etc

Приведу несколько аргументов (в сравнении с laravel):

1) Yii2 довольно слабо следует принципам SOLID и более того, не предоставляет в достаточной мере архитектурного решения разработчику, чтобы он сам им следовал
2) Yii2 Костылен, а его исходники мягко говоря не очень. Например behaviors (костыль) против middlware(прозрачное решение)
3) Yii2 Имеет устаревшие сервисы из коробки относительно Laravel , который развивается куда более активно.
Помимо прочего в Laravel намного больше готовых сервисов (Elixir , scheduling, Queue , Blade, Storage, Broadcast , Notifications) Вместо этого в yii2 есть только bower assets - который представляет с собой дикий костыль и откровенно ужасен, да еще и не безопасен, а также вроде в yii2 есть сервис для работы с файловой системой, но я с ним не работал. Остальные сервисы типа bootstrap , console etc есть и там и там
4) Магия Yii2 не способствует контролю за кодом и прозрачности
5) Yii2 имеет довольно плохо продуманную архитектуру, о чем говорит например тот факт, что jquery вшит в ядро фреймворка (возможно и некоторые другие ассеты) и это очень странно. Особенно когда тебе нужно запускать консольные приложения
6) ActiveRecord в yii2 доволбно запутан, по сравнению с https://laravel.com/docs/5.3/queries (кончено это субъективно)
7) Yii2 не особо популярен в мире, у него плохая документация и я думаю он серьезно отстоет от конкурентов.

Есть конечно у него и плюсы, например он быстрее laravel и у него есть поддержка модулей(что решается в laravel подключением пакета)

я обычно использую array для хранения, а в class Product указываю анотации что я там храню
например

class Product
{
/**
 * @var Path[]
 */
private $someProperty
/**
 * @var AnotherClass[]
 */
private $someProperty2
}

тогда имею в ide автокомлит например внутри циклов

Также для хренения коллекций есть SPL php.net/manual/ru/book.spl.php соответственно можно выбрать структуру данных и раньше даже было преимущество в скорости но сейчас бенчмарков нет и сказать наперед сложно, и проблема с автокомлитом в ide будет так как нет поддержки generic.

Ответ прост: перепродажа услуг ничего непонимающим человеком в 99.99% случаев: режим "роутера" => ведение двусторонней переписки в двух чат-окнах.

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

Если человек не хочет общаться голосом - он не компетентен в данном вопросе и просто этого избегает. (другие, еще хуже: только по почте общаются)

Итог: отказались поговорить и ответить на Ваши вопросы голосом - сразу же ищите следующего исполнителя. (или ориентируйтесь на скорость ответа в чате + время суток, что не советую)

Всё просто. В 99% ситуаций общения голосом, желают типичные "гуманитарии", которые от темы разработки бесконечно далеко. Ты им говоришь "напишите ТЗ", а они в ответ "давайте я лучше вам всё по телефону расскажу". Они думают если не разбираются в вопросе и не могут ТЗ написать, то уж голосом точно всё объяснят как надо. И не дай бог вам согласиться (а просят как правило настойчиво, ибо самим лень разбираться в вопросе и что-то писать), вынесут вам мозг по полной.

Как хранить бизнес-логику чтобы модели не превратились в монстров из десятков тысяч строк?

Тут не совсем модели. Entity - это просто объект данных, умеет хранить их в себе и бросать исключения, если не правильные данные вставляете, все. Repository - умеет работать со своим Entity И БД.

БЛ находится в классах сервисах.

Читал про Command Bus где, если правильно понял, на каждое действие в системе – свой класс?

Вообще под каждое дествие - не обязательно, тут нужно руководствоваться здравым смыслом.

Как их организуете (их тогда будут сотни)?

Иерархически. Путь к классу должен быть "понимаем".

Есть ли смысл выносить каждую доменную модель в модуль/микросервис, хранить всю связанную логику где-то там внутри, а с остальными общаться по внешнему API?

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

За ответы в клиентскую часть – отдельный сервис-фронтенд?

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

Каков оверхед?

Ничтожный.

Используют ли такое на практике?

Да

Какие подводные камни?

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

Как не превратить кидание/получение событий типа PostBeforeEdit/PostBeforeEditHandler в "callback hell"?

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

Функционал "PostBeforeEdit/PostBeforeEditHandler" часто дешевле и проще вынести в сервис, но опять же руководствуйтесь здравым смыслом.

ACL Где храните указанную логику?

Если ACL будет не тривиальный - готовьте себя к тому, что он будет размазан по уровню контроллеров.

Какие структуры для описанного выше – best practice?

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

В моём понимании это выглядит как куча трёхмерных кубов доступа "crud – group – entity – field", как это сделать более плоским пока только одна идея – делать кучу таблиц many-to-many.

Гибкая настройка вплоть до каждого поля 90% что не нужна. Если можно свести к понятию скопов прав - сделайте это.
Структуру можно предлагать только зная ваш проект.

Версионирование. Как вы версионируете подобные проекты?

Semver.

А если нужна "N-1" рабочая версия на продакшене?

Значит на прод попадает ваша версия с тегом "N-1"))

Есть ли смысл разделять версии в рамках единой кодовой базы проекта и как (неймспейсы, конфиг, модуль, что-то ещё)?

Храните яйца в отдельных корзинках. Если модуль развивается полностью отдельно и может быть вынесен как зависимость проекта в vendor - делайте.

И, самое главное – как всё это совместить?

• РУКОВОДСТВУЙТЕСЬ ЗДРАВЫМ СМЫСЛОМ
  
• Принимаете жесткие соглашения по правилам написания кода, например такие
  
• Постарайтесь убедить бизнес в том, что без покрытия кода автотестами будет дороже, нестабильней и дольше. + Пишите тесты. Если объем тестов в 4 раза больше кода, который они тестируют - это норм. У меня бывали случаи, когда для критичного функционала тестов было в ~16 раз больше, чем кода.
  
• Жесткие, обязательные кодревью.
  
• Если задача крупная - декомпозируйте ее.
  
• Технический долг - возвращайте обязательно И как можно скорее.
  
• Перед тем как писать код для работы с внешним сервисом - имеет смысл написать его эмулятор.
  
• Спешите только в случае серьезных проблем на проде)). Фичи "на вчера" отличаются от фич "на потом" только приоритетом выполнения, более ничем.
  

Как их организуете (их тогда будут сотни)?

Раскидываю по неймспейсам. Скажем все действия относящиеся к юзерам находятся в папке Users.

Только вы учитывайте что CQRS это прикольно но особо не нужно. К примеру это сразу подразумевает что вы используете UUID вместо автоинкрементов и прочей чуши. Можете сделать хотя бы как Дядя Боб предлагает в своей Clean Architecture. Просто сервис на каждое действие.

Есть ли смысл выносить каждую доменную модель в модуль/микросервис

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

Раньше для дополнительных действий мне достаточно было использовать что-то вроде beforeUpdate/afterCreate модели.

ну а сейчас вы будете эти вещи в сервисы пихать. Причем возможно не в один сервис. Вообще старайтесь не делать "хуков" и не будет с ними проблем. Есть к примеру DomainEvents такая штука, ну и можно все эти "дополнительные действия" в хэндлерах команд делать.

Как не превратить кидание/получение событий типа PostBeforeEdit/PostBeforeEditHandler в "callback hell"?

Просто забудьте об этих ивентах.

ACL. Где храните указанную логику?

Есть в симфони security vouters, а дальше все зависит от того что вы делаете.

Как вы версионируете подобные проекты? А если нужна "N-1" рабочая версия на продакшене?

git + docker теги в мастере. Ветки нужно плодить только тогда, когда у вас система деплоится кастомерам и нужно поддерживать сразу кучу версий. Называется это gitflow.

На какие проекты (точнее, на код) можете посоветовать посмотреть для лучшего понимания? Ссылки на репозитории?

На гитхабе катострофически мало примеров хороших приложений на симфони. Да и не только на симфони - в принципе найти в открытом доступе сложный проект - это нереально. NDA и все такое. Такие системы обычно очень дорогие и закрытые со всех сторон.

p.s. почитайте книжки:

- Эрик Эванс - Предметно ориентированное проектирование
- Крэйг Ларман - Применение UML 2.0

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