по UI: хорошие курсы по Axure доступны @ВК/YouTube от Егора Камелева, которые так же должны дать общее представление о том как должен думать проектировщик интерфейсов. доступно, а главное адекватно и аргументированно раскрывает по сути бизнес-секреты проектирования интерфейсов в роликах и вебинарах. мне хватило пары. дальше Вам (в теории) должен помочь опыт сёрфинга (а точнее залипания годами и десятками лет) в сети, что позволит интуитивно понимать какому посетителю что и где нужно показать, а что - спрятать. думаешь его головой на автомате, а точнее представляешь его действительную (а не надуманную) реакцию на элементы управления и особенности психологии восприятия оформления и композиции)

"ехать за границу и учиться в дизайн студиях" - нафиг ехать за бугор, когда всегда и во всём нужен просто нормальный, адекватный наставник, т.е. дело в учителе, а не в стране. первое, что приходит на ум: у нас уже есть и успешно функционируют две классные школы: Артёма Горбунова и Артёма Лебедева, и если во второй царит этакая богема, хаос, можно бухать на работе и курить "лишь бы работалось зае...сь" и всё там ультракреативно априори (кому как, к слову, хотя идеи нередко сочные, но не всегда и не во всём), то в школе Артёма Горбунова более цивилизованный, системный и вполне продуманный подход по приведению в чувства подающих надежды с шансами выхода на уровень действительных профессионалов, коих, как и рил хакеров, в реале на весь мир - очень и очень мало. и там, кстати, есть бесплатные места, но надо будет поднатужиться с подготовкой, а потом капитально попариться с тем чтобы не вылететь. но это того стоит)

PS и сразу по результатам заказчиками нагрузят, btw

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

Следующий вопрос,как организовать передачу этого самого id_people в таблицу комментарии?

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

PS чтобы подойти с нужной стороны определите сначала для себя в голове такие понятия как:
- реляционная СУБД
- структура таблицы реляционной СУБД
- поля таблицы
- колонки таблицы
- внешний ключ (одна из тех самых колонок, связывающий те самые поля одних таблиц с другими через их значение)

доки из моих закладок по JOIN
100 различных вариантов толкования одного и того же (максимально доходчивых для меня)
- MySQL немного о JOIN'ах
- Наглядное объяснение принципа объединения таблиц в...
- Объяснение SQL объединений JOIN: LEFT/RIGHT/INNER/OUTER
- MySQl: использоваение операторов JOIN на примерах
- Разработка → MySQL и JOINы

ну и когда подтянитесь уже - Top 20+ MySQL Best Practices

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

удачи!

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

(дока описывает техпроцесс разработки web-приложения малого масштаба, хотя мб и для среднего подойдёт)

Подготовка к проектной работе
=====================================
1. Требования
1.1. Постановка задачи (оценка и установка лимитов ресурсов и сроков разработки)
1.2. Основные функции (общее описание выполняемых задач)
1.3. Требования к архитектуре
1.3.1. Планы по поддержке проекта
1.3.2. Используемые технологии (исходя из планов по поддержке)
1.3.3. Архитектурное решение (исходя из использ. технол., модульн., монол., слои и т.п.)
1.3.3.1. Сопряжение со сторонними технологиями/ПО
1.4. Описание целевой аудитории (конечные пользователи, их навыки, восприятие, UX)
1.5. Сроки выполнения (на разработку, на интерфейс, на тестирование, на развёрыв.)

2. Техническое задание (на основе требований и дизайн-макета)
2.1. Платформа (связки ПО, с версями и конфигурациями)
2.2. Структура проекта (блок-схема с разделами и подразделами FE и BE)
2.3. Бизнес-объекты (их структура/свойства, действия над ними, и их поведение)
2.4. Бизнес-процессы (алгоритм линейных процессов на основе бизнес-объектов)
2.5. Политика безопасности
2.5.1. Списки доступа (описание разрешений для ролей / групп пользователей)
2.5.2. Меры обеспечения безоп. (библиот., алгоритмы, порядок восст. доступа, ...)
2.6. Принцип хранения данных
2.6.1. Устройство хранилища файлов (форматы, способ хранения)
2.7. Макет интерфейса (базовый макет + детальные черновики всех страниц)
2.8. Поведение интерфейса
2.9. Дизайн-макет (гайды, нормы, правила, черты единого стиля)
2.9.1. Палитры (палитры разделов и типов страниц сайта, для печати, служебные)
2.9.2. Отступы, размеры, геометрия, горизонтальный ритм
2.9.3. UX / особенности и правила поведения интерфейса
2.10. Roadmap проекта (на основе предыдущих пунктов)
 
Проектирование архитектуры и разработка
=====================================
3. Проектирование (исходя из выбранной политики безоп., на основе ТЗ и требований)
3.1. Cтруктура приложения (детальное описание; URL map, routing, описание actions)
3.1.1. Структура web-приложения (модули, контроллеры и actions)
3.1.2. Карта внутренних маршрутов URL-адресов
3.2. Объектная модель «общего домена» (UML-диаграмма классов)
3.3. Проектирование БД (DDL-диаграмма, SQL-файл, альфа-версия)

4. Backend
4.1. Заготовка Yii2-приложения (config, namespaces, контроллеры, actions, views)
4.1.1. Создание заготовок actions (пустых файлов, либо конфигур. и подкл. базовых)
4.1.2. Подготовка View-файлов (создание пустых + конфигуриров. работы с шабл.)
4.2. Написание УК (управл. код - вызовы функций классов общего домена в actions)
4.3. Разработка вызванных в УК функций (расширение API, функционала библиотек)
4.4. Доработка БД (DDL-диаграмма, SQL-файл, бета-версия)
4.5. Внедрение отладочного функционала
4.6. Генерация тестовых данных приложения в БД
4.7. Описание ключевых аспектов кода (для упрощения поддержки проекта)

5. Интерфейс
5.1. Базовый макет (композиция из блоков, на основе дизайн-макета, подбор grid system)
5.2. Сценарии интерактивности и поведение UI (описание интерактивной части)
5.3. Настройка компонентов и контента (настр. yii\Asset’s, загрузка изображений UI)
5.4. Подключение новых Jade-шаблонов
5.5. Прототип. Базовая Jade-вёрстка (допустимо: приблизительное соотв. макету)
5.6. Javasript/CSS-интерактивность
5.7. Косметика UI (pixel-perfect вёрстка с соблюдением всех требований к дизайну)

Завершение разработки. Развёртывание.
=====================================
6. Развёртывание
6.1. Предстартовая отладка (нагрузочное тестирование, безопасность, ..)
6.2. Комплексная доработка всех частей приложение

мною пока пройдена первая треть и ряд пунктов из UI, вся часть по проектированию и арх. БД и каркаса приложения (а это значит, что всё это ещё может меняться, переставляться местами, удаляться и добавляться ещё не раз и не три.., будьте бдительны!), т.к. начал я писать ТЗ (к Вашему недоумению) где-то на середние разработки, поняв, что это тут будет очень кстати и сейчас и, особенно, потом.

.. +, помимо прочего эти доки (почти каждый пункт в списке - отдельный документ, файл, диаграмма или законченный объект/набор чего-то проектно-полезного) помогли мне мне лучше понять механику продакшена ПО, то самое магическое нечто, что позволяет коду выполнять хотелки, т.е. полноценная, грамотная и красивая реализация прикладных задач (то,ради чего ПО и пишется, но совсем не всегда выполняет свои задачи грамотно, нормально и вообще адекватно.. и вообще выполняет ли - думаю многие видели эти ужасные неповоротливые (в т.ч. enterprise-oriented) решения, с которыми проблем больше чем пользы, ту же Ультиму, к слову, уже сколько лет внедряют в Юлмарте, или уже внедрили, я хз, но, столько лет и млн. денег слито - смех и грех..)

Павел Волынцев, Александр Аксентьев
есть ощущение, что чел просто хочет реализовать и оттюнить BL с заглушками-эмулями в CRUD-функциях в самом низком слое уровня манипуляций с атомарными (в рамках домена) сущностями хранилища, и ему это трудно делать, т.к. думает он не с той стороны как остальной мир.

diamond это можно, но подводные камни в данном случае я предполагать даже не буду какие,
при том, что в теории, изначально вы должны выиграть, но вот какой ценой.. хотя бы даже по времени
и ресурсозатратам на адаптацию проекта к существующей общей экосистеме разработки, принятой
на сегодняшний день во всём мире и соответствующих знаниях и наработках, доступных для широкой
публики исходя из сложившихся практик. думаю Вам стоит написать несколько готовых проектов, и
тогда будет проще видеть систему в разных проекциях, разрезах и степенях свободы (понятия BE/FE в зависимости от контекста, как кирпичами выполняются бизнес-задачи и на их основе системы
выполняют уже глобальные задачи исходя их бизнес-правил, какие компоненты на каких уровнях и как взаимодействуют), и потом уже в голове легко рисовать себе будете кубики в стиле BPMN с привязкой к реальности и без фантазёрства

это лишь моё предположение. за советом, думаю, лучше к Павел Волынцев, у человека неплохое портфолио