iceas

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

Тут мой ответ по связанной теме: Как составить план проектирования проекта?
А кроме того, хочу отметить, что начинать проект с дизайна (если Вы имеете в виду дизайн пользовательского интерфейса) это в большинстве случаев очень плохая практика. Проект нужно начинать с концепции, а потом переходить к информационной модели, потом к структурам данных (как в базе, так и в памяти) и уже потом только понятно, что на экране будет делаться. Исключение могут составлять игры, электронные книги, анимационные, интерактивные и подобные произведения, которые являются в большей степени произведением визуального искусства, чем программным продуктом. Из средств проектирования посмотрите разные реализации UML и RUP (Rational Unified Process), например Rational Rose. Вот, посмотрели, и понравилось - берите, а стало страшно - значит это Вам не нужно. Это для проектов крупных и очень крупных. Что точно нужно, так это уметь рисовать ER-диаграммы на бумажке карандашом, архитектуру модулей программной системы и железную инфраструктуру для развертывания. На большинство вопросов, которые Вы задаете, ответы можно дать только относительно конкретного проекта. Иногда нужны автоматизированные средства проектирования, иногда они не нужны и все можно сделать в уме и сэкономить время. Это очень зависит от задачи и опыта. Но что определенно, так не следует разводить лишней бюрократии,

Идея/концепция к проектированию не относится, это отдельный предварительный этап. Для проектов побольше, и в общем случае, проектирование включает такие шаги, многие из которых, конечно, можно пропустить или сократить до минимума, если задача не сложная:
1. Системный анализ и изучение предметной области
2. Формирование требований к разрабатываемой системе
3. Архитектуная задача, которая сводится к простой формуле: разделять, называть и связывать подсистемы
3.1. Декомпозиция сложных задач
3.2. Слои (построение слоев абстракций)
3.3. Планирование топологии системы, программной и серверной инфраструктур
3.4. Решение вопроса интеграции подсистем, программные интерфейсы, контракты и связывание
3.5. Интеграция с унаследованными приложениями
3.6. Минимизация изменений, для случаев, когда постоянно происходят изменения в предметной области
4. Выбор инструментов решения
4.1. Выбор парадигм программирования и языков
4.2. Выбор технологий и платформ
4.3. Выбор моделей данных, алгоритмов и библиотек
4.4. Выбор топологий и протоколов
4.5. Выбор паттернов программирования
5. Предварительные исследования
5.1. Проверка гипотез, эксперименты
5.2. Изучение особенностей технологий
5.3. Прототипирование
6. Задачи обеспечения надежности
6.1. Планирование безопасности и защиты от несанкционированного доступа
6.2. Планирование отказоустойчивости
6.3. Планирование мер по обслуживанию системы в режиме эксплуатации
6.4. Задачи высоких нагрузок, балансировки и масштабирования, если таковые предполагаются
7. Организация процесса разработки
7.1. Жизненный цикл программной системы
7.2. Конвенции кода, соглашения и стандарты
7.3. Оценка необходимых временных и финансовых ресурсов для разработки системы
7.4. Календарный план
7.5. Анализ и минимизация рисков, выявление слабых мест технологий и коллектива
7.6. Закрепление принципов управления процессом разработки и корректировки задания в процессе
8. Сборка технического задания из результатов всех предыдущих пунктов

Архитектурные принципы не очень связаны именно с нодой, они будут примерно одинаковыми, на каком бы языке вы не писали. Первое, что я могу посоветовать, когда Вы переходите от технологий программирования к архитектуре систем, это как переход от кладки кирпича к архитектуре зданий - нужно отложить все шаблоны, которые Вы знали до того и подняться на другой уровень абстракции. А именно, нужно перестать мыслить такими понятиями, как DI (dependency injection), REST, MVC, ORM, RPC, шаблонизаторы, компоненты, сокеты, промисы и прочее - это все технологии. Что же нужно понять это: слои (layers), модули, контракты, адаптеры, клиент-сервер, 3-звенная архитектура, микросервисы, СМО (системы массового обслуживания), и т.д. Где так все собрано в одном месте - не могу сказать, я лично по крупицам все осваивал, на что положил 20 лет профессиональной деятельности. Почитайте про ISO/OSI, загляните в три мои статьи habrahabr.ru/post/227753 и habrahabr.ru/post/204958 и habrahabr.ru/post/117791 Раньше хорошие статьи по архитектуре были на www.osp.ru но, к сожалению, давно не читал его. Можно начать с книг Гради Буча и освоения UML, этот дядька сформировал достаточно полный подход и методологию проектирования программных систем, которая ведет правильным путем, но на практике, в каждом отдельном случае может быть заменена интуицией архитектора и существенно упрощена. Удачи!

Берите ноду, на ней тоже уже все есть готовое в NPM, не меньше, чем на RoR, но не подсядьте только на "все из коробки", главное определиться для со стеком технологий и адхитектурой, это важнее, чем язык, сейчас разрабатывают больше даже на фреймворках, нежели на языках. Определитке задачи для себя, что Вы хотите решать на ноде, что писать, для чего использовать: обычные сайты или CMS, SPA-сайты сайты или SPA-приложения, Rich-приложения, адаптированные под мобильные или будете заниматься только backend и работать в команде с кем-то, кто будет писать frontend. Нужно выбирать все в комплексе, СУБД, фреймворк для браузера, серверную ОС, варианты хостинга. Я рекомендую такой стек: CentOS, Node.js, MongoDB / PostgreSQL, React. Какие ссылки советую:
1. Моя статья на Хабре - habrahabr.ru/post/204958
2. Мой ответ на вопрос по фреймворкам для ноды тут на Тостере - Подсоветуйте фреймворк для node?
3. Видео-уроки по node.js - learn.javascript.ru/nodejs-screencast
4. Про Impress - habrahabr.ru/post/247543
5. Разнообразные ответы по поводу выбора языка - Актуальный язык программирования