Глянул на пэт-проект, который сейчас пишу - 5тыс строк + 1тыс тестов, и если честно, ощущение, что проект даже не начал ещё толком писать.

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

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

PS хотел бы ещё важное добавить, архитектурными делами надо заниматься не наскоками. Тут как back-end <-> front-end, мне например сложно перескакивать с одного на другое в течение дня, большие задачи делаю только одно, или back или front.
С архитектурой также надо поступать. Потому, что сложно переключать мышление с глобальных абстракций на детали реализации.

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

GroupBy(x => x.Name == "apple" || x.Name == "banana" ? "apple+banana" : x.Name);