Читаю сейчас книгу "Фундаментальный подход к программной архитектуре" Марка Ричардса, второе издание. Попутно с чтением делаю записи конспектов в Obsidian. Все это нужно для собственного развития как архитектора 1С (о непрерывном развитии кстати также говорится в книге, так что я все правильно делаю). Наткнулся на книгу случайно, обсуждая в беседе с дипсиком вопросы организации элементов проекта для технологии 1С:Элемент с учетом методологии Чистой архитектуры. Причина простая - я начал путаться в размещении большого количества объектов в проектах на Элементе и решил выяснить хорошие практики в этой части.

Вот некоторые результаты изучения и погружения в эту тему: 1) Чистая архитектура заставляет нас делить все по подсистемам Элемента, внутри которых мы группируем все по пакетам а-ля: метаданные, модули, компоненты, командный интерфейс. Но данная архитектура ведет к появлению очень большого количества файлов и в том числе ведет к переусложнению решения для большинства разработчиков. 2) Альтернативный вариант - группировка по функциональному назначению. Мы в один пакет собираем все элементы проекта что к нему относятся: объект метаданных, формы, команды, кодовую базу, контракты и прочая. Навигация упрощается, повышается внутренняя связность элементов между собой, при этом если что выпилить функционал будет в разы проще. Этот подход нарушает ту же самую чистую архитектуру, но при этом рекомендуется вендором. 3) Пошел искать истину при таких явных противоречиях. Наткнулся на книгу в рекомендациях ИИ, сначала попросил краткий пересказ, понял что ИИ нифига не знает о книге, пошел гуглить. Нагуглил, понравилось, купил на Яндексе электронную версию. 4) Первой же главой книга говорит - архитектура, это не идеальное решение. Это набор компромиссов и принятия минусов, поиск наименее худшего решения среди всех решений. То есть все равно будет какая-то фигня. К тому же на каждом проекте надо выбирать свою архитектуру с учетом обстоятельств и неявных требований. Идеального решения никогда не будет - смиритесь. 5) Ну а чтобы подбирать наименее худшее решение, надо постоянно развиваться и расширять свой кругозор, расти вширь, а не в глубь. Только тогда можно будет повысить качество принимаемых решений в программной архитектуре, от которой зависит очень многие аспекты в разработке ПО. И никакая общедоступная нейросеть тут не поможет, поскольку у нее не будет самого главного преимущества архитектора - опыта, насмотренности и развитых навыков синтеза.