Vicom

шикарный вопрос. ответ - Ваш будущий опыт) всё индивидуально, вот например мой путь (сам себе разработчик, дизайнер, архитектор, менеджер проекта и чёрти кто ещё там в студиях штаны просиживает), далеко от завершённости, но точно может дать на Ваш ответ. а конкретное ПО - дело исключительно Ваше. я UML-редактор выбирал себе недели две где-то только, у каждого свои требования и уровень критичности восприятия фич ПО для работы)

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

(дока описывает техпроцесс разработки 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) решения, с которыми проблем больше чем пользы, ту же Ультиму, к слову, уже сколько лет внедряют в Юлмарте, или уже внедрили, я хз, но, столько лет и млн. денег слито - смех и грех..)

что Вы документируете? от этого во многом будет зависеть ответ

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

блин ну реально выше сказали вон)

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

Session::setAccessLevel(Auth::ACCESS_GROUP_ADMIN);

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

- сделайте запрет как-нибудь на прямую работу с _SESSION хз, или

- бейте по рукам при его вызове (всё должно быть по регламенту через свои интерфейсы/классы/обёртки или фреймворка. если человек делает c _SESSION / _GET / _POST etc. это уже насторожить должно, если апликуха написана на fw), на худой конец

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

.., а вообще от всех возможных чужих дуростей не спасёшься

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

в качестве домашнего задания неск. месяцев поставил сам себе задачу, которая, видимо, делает то, о чём Вы говорите. Вопрос на тостере с участием проекта Catalog Master (третье изображение в вопросе) - это оно?

..>dropDownList(['Киев' => 'Киев, 'Винница' => 'Винница,]) ?>

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

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

так же полезно копаться в готовом коде, о чём не раз тут уже упоминали, это и поможет понять как делать лучше и научит разбираться в чужом коде и исключит массу проблем. примеры: магазин на Yii2 - DotPlant. вперёд на их github-репозиторий, из первого Yii сделали в своё время хороший Yupe, так же полезно, только читайте осторожно, чтобы не учиться старому коду, т.к. в новом (лучше писать свой код сразу на Yii2, на мой взгляд) потом ошибок наделаете

и не ленитесь спрашивать у Google, там вагон и телега по теме

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

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

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

перепишите вопрос на русский, пожалуйста, что за

организовать связь один ко многим в Агрегате

(есть понятие Агрегации, но про Агрегаты я слышу впервые)

доступаться

(песня без слов, ночь без сна..)

..либо я серость и всё это термины из области, о которой я слишком не слышал,
т.к. изначально читаю это и думаю метамоделью UML сразу же

%публика%, растолкуй кто в лес, а кто по дрова, я только проснулся? )

Следующий вопрос,как организовать передачу этого самого 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 и покупать в реале - самое то для нормалього понимания сути.

удачи!

не знаю смотрели ли.. скролл вниз и тут же по Вашей теме:
Есть ли библиотека на php для работы с nested sets?
Хочу понять алгоритм перемещания узла в дереве nes...

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

Не будет такого названия "веб-дизайнер, специальность №102067", нету такого в нашем гос. реестре, инженер в трудовой это называется, или техник. можно представить как "специалист в области автоматизированных систем и усправления - АСУ", если идти по пути нотации той спеки на которую идёшь учиться, например в Бонч-Бруевича. К слову, зря про ИТ гон на универы. в Питере (по крайней мере, откуда Вы - не знаю) есть минимум 4 приходящих на ум культовых ВУЗа - Телекоммуникаций им. Бонч-Бруевича, Политехнический, ЛЭТИ, ИТМО - они МИРОВОГО УРОВНЯ (причём считаются именно ЛУЧШИМИ, а не просто в плоскости с сотнями других зарубежных). Кто Вам сказал такую чушь про ИТ - не знаю, и надеюсь, Вы пересмотрите свою позицию. Хотя в своё время я ушёл из универа недоучившись, т.к. знания, которые я получил через полгода на моём первом рабочем месте только начинали маячить перед моими сверстниками аж через 3-4 года. причём только в теории. Но. Это было давно (2005 год, кажется), и это было в узкой сфере безопасности, которая начинала только зарождаться тогда, теор база нулевая, практика тоже, законы дырявые и проседают по определениям конкретнее некуда, т.к. вся отрасль = "мир 20 лет назад". Сейчас инфа про корявость обучения уже неактуальна.

..а Иннополис?! Да бог с Вами..

А что за страна, кстати?

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

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

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

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