пффф, все правят код чтобы покрыть его тестами, все

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

так.... короч попробую направить дискуссию в что-то более содержательное.

для начала надо определиться с проблемой. Какую именно проблему ты хочешь решить. Пока вижу вот это

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

это вот достаточно субъективно что бы предметно обсуждать. Сразу скажу выкинуть к чертям "элегантность" и сфокусироваться на двух аспектах - что для тебя поддерживаемость и как ты ее меряешь, а так же что ты подразумеваешь под "реюзом" и не пал ли ты жертвой "реюз ради реюза"? И что значит "сложно покрывать"

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

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

это не поможет научиться

обычно проблема именно в осознании "а почему вообще условная луковая архитектура считается чем-то хорошим"

"копировать" не поможет с этим

елси вопрос стоит именно так, то тогда я бы читал статьи вида "что хорошего в архитектуре Н"

ну и пачки пет проектов на каждую архитектуру

это опять же плохая формулировка - хорошая - "зачем".

мне кажется проблема именно в фиксации на "примерах" без попыток осознать более общие правила

зачем ? в виде отсебятины - чтобы разбираться в плюсах и минусах разных подходов

луковая архитектура это все же "пример"

"зачем нужны те или иные вещи в тех или иных подходах, какие проблемы те или иные подходы решают"

еще немаловажно разбираться "зачем тот или иной функционал ты пилишь" так как это в последствии является драйвером для осознания что и как надо изолировать от чего и при должном погружении в предметную область позволяет лучше прогназировать что и как будет меняться

там нет архитектуры, хотя я не читал, но название говорит про структуры данных... какая архитектура?

а я бы почитал чего типа "программист прагматик"

и наоборот рекомендовал бы на время отложить вопрос "архитектуры" и разобраться с более общими концепциями - например information hiding.

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