ToshiDono

А можно подойти к этому вопросу математически и найти простое решение:
1. Гуглим - 5-10 минут.
2. Если не нагуглили - спрашиваем.
3. Если нагуглили - разбираемся.

В целом, при простых вопросах, чтобы разобраться самому потребуется меньше времени, чем на то, чтобы расписать ситуацию тому, у кого спрашиваем.

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

Тут мой ответ по связанной теме: Как составить план проектирования проекта?
А кроме того, хочу отметить, что начинать проект с дизайна (если Вы имеете в виду дизайн пользовательского интерфейса) это в большинстве случаев очень плохая практика. Проект нужно начинать с концепции, а потом переходить к информационной модели, потом к структурам данных (как в базе, так и в памяти) и уже потом только понятно, что на экране будет делаться. Исключение могут составлять игры, электронные книги, анимационные, интерактивные и подобные произведения, которые являются в большей степени произведением визуального искусства, чем программным продуктом. Из средств проектирования посмотрите разные реализации 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. Сборка технического задания из результатов всех предыдущих пунктов

Часто применяется для:

1. Локальные приложения и утилиты командной строки

• Сборщики и трансляторы
  
• Пакетная обработка и сценарии отложенной обработки
  
• Скрипты, CLI (интерфейсы командной строки)
  
• Генерация документации, отложенное формирование отчетов
  
• Сценарии тестирования для других систем
  

2. Серверы

• Серверы веб-приложений и SPA
  
• Серверы и API для мобильных приложений
  
• Любые другие веб-API (RPC, JSON, REST)
  
• Серверы сообщений и трансляция событий (чаты, игры, интерактив)
  
• Заплаты на уже готовые системы, написанные на других языках, для реализации вебсокетов, SSE, лонг-пулинга и т.д., т.е. для затыкания дыр, для решения проблем в узких местах уже работающих систем.
  

3. Клиенты

• Оконные приложения (nw.js, node-webkit)
  
• Кравлеры, парсеры и сбор данных
  

4. Железо

• Программирование микроконтроллеров (arduino, espruino, tessel)
  
• Промышленная автоматизация
  

Редко применяется (но подходит) для:

• CMS, публикация контента (просто ниша уже занята и в этой задаче нода не дает чего-то принципиально нового или сверх соблазнительного).
  
• Массовая электронная коммерция и торговля (не применяется для массовых движков магазинов, но используется отдельными крупными компаниями для торговых и платежных задач в качестве дополнительного средства к уже имеющемуся ПО, по сути закрывает узкие места).
  

И плохо подходит:

• Вычисления и моделирование, со скоростью математических операций нода и JS, как не типизированный язык, не дают хороших показателей
  
• Научные приложения (по тем же причинам)
  

Архитектурные принципы не очень связаны именно с нодой, они будут примерно одинаковыми, на каком бы языке вы не писали. Первое, что я могу посоветовать, когда Вы переходите от технологий программирования к архитектуре систем, это как переход от кладки кирпича к архитектуре зданий - нужно отложить все шаблоны, которые Вы знали до того и подняться на другой уровень абстракции. А именно, нужно перестать мыслить такими понятиями, как 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. Разнообразные ответы по поводу выбора языка - Актуальный язык программирования

Вышка в России для программиста играет весьма малую, а порой и дурную роль.

Лично я сразу после техникума (не IT направления) пошел в разработчики, был полностью самоучкой. В итоге пережил разработчиков которые были с вышкой, стал начальником отдела, и теперь когда принимаю на работу нового разработчика, мне вообще по барабану какое у него образование. Мне главное чтобы глаза у человека горели своей профессией, остальное побоку, научим) Тем более сразу готовых кадров, которые подойдут по всем требованиям найти очень сложно. Берешь живой материал и доучиваешь. А если кандидат еще и будет понимать что взяли его с авансом, то можно веревки вить, будет с удовольствием перерабатывать чтобы набраться как можно больше опыта, реальных навыков которые нужны для профессии)

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

Относительно IT образования в России все не столь круто) И будет оставаться столь же не круто доколе Бизнес сам не станет обучать кадры. С первого курса. Не учителя которые отошли от дел пару десятков лет назад, а реальные специалисты которые крутятся в перспективных направлениях, которые будут вести лекции в Вузе. Так происходит в крутых ВЗ западных стран. Считаю это единственно верным способом обучения в ВУЗах компетентных специалистов.
Некоторые ведущие ВУЗы кстати уже пытаются прийти к этой модели, создавая новые IT специальности и сразу заключающие соглашения с крупными или ведущими IT компаниями чтобы они с первого курса выделяли специалистов для обучения. Надеюсь пока эти отчасти экспериментальные специальности не только приживутся, но и вскоре перенесут данную модель обучения на все остальные специальности крупнейших ВУЗов страны)