Чистая архитектура в 1С: возможно ли это и как её построить

Что такое чистая архитектура простыми словами?

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

Основные принципы чистой архитектуры:

Разделение ответственности — каждый модуль отвечает за свою задачу. Модуль работы с документами не должен заниматься отрисовкой форм.

Независимость от фреймворка — бизнес-логика не должна быть намертво привязана к платформе 1С.

Тестируемость — код можно проверить без запуска всей системы.

Направление зависимостей — внутренние слои не знают о существовании внешних. Бизнес-правила не зависят от того, как данные хранятся в базе.

Особенности платформы 1С

Прежде чем говорить о чистой архитектуре, нужно понять специфику 1С. Это не просто язык программирования, а целая платформа со своими правилами игры.

Встроенный язык и метаданные тесно связаны между собой. Нельзя просто взять и написать код отдельно от конфигурации — всё живёт внутри платформы.

Объектная модель навязывает определенную структуру. Документы, справочники, регистры — это не просто классы, а объекты со встроенным поведением.

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

Формы и интерфейс создаются через конфигуратор, а не пишутся кодом с нуля.

Звучит так, будто чистая архитектура невозможна? На самом деле нет, просто нужен адаптированный подход.

Возможна ли чистая архитектура в 1С?

Короткий ответ: в классическом виде — нет, но можно создать что-то близкое и очень полезное.

1С не даст вам полной независимости от платформы. Вы не сможете взять бизнес-логику и перенести её в Python или Java. Но вы можете организовать код так, чтобы он был понятным, поддерживаемым и относительно независимым от конкретных реализаций.

Главная цель — не достичь идеальной чистой архитектуры из учебника, а написать код, который легко понимать и изменять. Это гораздо важнее теоретической чистоты.

Слои архитектуры в контексте 1С

Давайте разберем, как можно выделить слои в типичной конфигурации 1С.

Слой представления

Это формы, команды, отчёты — всё, с чем взаимодействует пользователь. В этом слое минимум логики, только работа с интерфейсом.

❌ Плохой пример:

// В модуле формы документа
Процедура ПровестиНаСервере()
    // Сразу пишем в базу, считаем, проверяем
    Запрос = Новый Запрос;
    Запрос.Текст = "ВЫБРАТЬ ...";
    // 50 строк кода с расчётами
    Объект.Записать();
КонецПроцедуры

✅ Хороший пример:

// В модуле формы
Процедура ПровестиНаСервере()
    МодульДокументов.ПровестиДокумент(Объект);
КонецПроцедуры

Слой бизнес-логики

Здесь живут правила вашего бизнеса. Как рассчитать скидку, когда можно провести документ, какие проверки нужно выполнить.

В 1С это обычно общие модули с серверным контекстом. Хороший тон — разделить их по доменам: работа с ценами, работа с остатками, расчёт зарплаты.

// ОбщийМодуль: РаботаСЦенами
Функция РассчитатьИтоговуюЦену(Номенклатура, Количество, Контрагент) Экспорт
    БазоваяЦена = ПолучитьБазовуюЦену(Номенклатура);
    Скидка = РассчитатьСкидку(Контрагент, Количество);
    Возврат БазоваяЦена * Количество * (1 - Скидка / 100);
КонецФункции

Функция РассчитатьСкидку(Контрагент, Количество)
    // Здесь только логика расчёта
    Если Количество > 100 Тогда
        Возврат 15;
    ИначеЕсли Контрагент.VIP Тогда
        Возврат 10;
    КонецЕсли;
    Возврат 0;
КонецФункции

Обратите внимание: функция не знает, откуда берутся данные и куда они записываются. Она просто выполняет расчёт.

Слой доступа к данным

Этот слой инкапсулирует работу с базой данных. Все запросы, чтение и запись объектов должны быть здесь.

// ОбщийМодуль: РепозиторийНоменклатуры
Функция ПолучитьБазовуюЦену(Номенклатура) Экспорт
    Запрос = Новый Запрос;
    Запрос.Текст = 
    "ВЫБРАТЬ
    |    ЦеныНоменклатуры.Цена
    |ИЗ
    |    РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
    |ГДЕ
    |    ЦеныНоменклатуры.Номенклатура = &Номенклатура";
    
    Запрос.УстановитьПараметр("Номенклатура", Номенклатура);
    Выборка = Запрос.Выполнить().Выбрать();
    
    Если Выборка.Следующий() Тогда
        Возврат Выборка.Цена;
    КонецЕсли;
    
    Возврат 0;
КонецФункции

Теперь если изменится структура хранения цен, вам нужно будет поправить только этот модуль.

Практические приёмы для улучшения архитектуры

Общие модули вместо кода в объектах

Не пишите всю логику в модулях документов и справочников. Выносите её в общие модули.

Вместо:

// Модуль документа РеализацияТоваров
Процедура ОбработкаПроведения()
    // 200 строк логики
КонецПроцедуры

Делайте:

// Модуль документа
Процедура ОбработкаПроведения()
    МодульРеализации.Провести(ЭтотОбъект);
КонецПроцедуры

// ОбщийМодуль: МодульРеализации
Процедура Провести(Документ) Экспорт
    // Логика проведения
КонецПроцедуры

Используйте параметры вместо глобального контекста

Передавайте данные явно через параметры функций, а не тянитесь к глобальным переменным.

Плохо:

Функция РассчитатьСумму()
    // Берём данные из неизвестно откуда
    Возврат Объект.Цена * Объект.Количество;
КонецФункции

Хорошо:

Функция РассчитатьСумму(Цена, Количество)
    Возврат Цена * Количество;
КонецФункции

Разделяйте чтение и запись

Один модуль читает данные, другой обрабатывает, третий записывает. Это упрощает тестирование и понимание кода.

Минимизируйте логику в формах

Формы должны только показывать данные и реагировать на действия пользователя. Всю обработку выносите в серверные модули.

Создавайте фасады для сложных операций

Если операция включает много шагов, создайте единую точку входа.

// ОбщийМодуль: ФасадОформленияЗаказа
Процедура ОформитьЗаказ(ДанныеЗаказа) Экспорт
    ПроверитьДанные(ДанныеЗаказа);
    Заказ = СоздатьДокументЗаказа(ДанныеЗаказа);
    РезервироватьТовары(Заказ);
    ОтправитьУведомление(Заказ);
    Заказ.Записать();
КонецПроцедуры

Типичные ошибки и как их избежать

Ошибка первая: всё в одном модуле. Разработчик создаёт огромный общий модуль, где лежат функции на все случаи жизни. Разделяйте код по смыслу: модуль для работы с ценами, модуль для работы с остатками.

Ошибка вторая: логика размазана по формам. Одна и та же проверка или расчёт копируется в десяток форм. Выносите повторяющийся код в общие модули.

Ошибка третья: запросы везде. Код напрямую обращается к базе из любого места. Создавайте репозитории для работы с данными.

Ошибка четвёртая: зависимость от деталей. Бизнес-логика знает про структуру форм или конкретные поля базы данных. Изолируйте детали реализации.

Ошибка пятая: игнорирование модульных тестов. Если код нельзя протестировать, значит архитектура плохая. Пишите код так, чтобы его можно было проверить отдельно от всей системы.

Пример рефакторинга реального кода

Представим типичную ситуацию: обработка документа реализации.

До рефакторинга:

// Модуль документа РеализацияТоваров
Процедура ОбработкаПроведения()
    // Прямо здесь проверяем остатки
    Запрос = Новый Запрос;
    Запрос.Текст = "ВЫБРАТЬ Остатки...";
    // Считаем суммы
    ИтоговаяСумма = 0;
    Для Каждого Строка Из ТабличнаяЧасть Цикл
        Строка.Сумма = Строка.Цена * Строка.Количество;
        ИтоговаяСумма = ИтоговаяСумма + Строка.Сумма;
    КонецЦикла;
    // Записываем движения
    Движения.ТоварыНаСкладах.Записать();
    // Проверяем контрагента
    Если НЕ Контрагент.Активен Тогда
        ВызватьИсключение("Контрагент заблокирован!");
    КонецЕсли;
КонецПроцедуры

После рефакторинга:

// Модуль документа
Процедура ОбработкаПроведения()
    МодульРеализации.Провести(ЭтотОбъект);
КонецПроцедуры

// ОбщийМодуль: МодульРеализации
Процедура Провести(Документ) Экспорт
    ВалидацияКонтрагентов.Проверить(Документ.Контрагент);
    РасчётСумм.РассчитатьСуммыДокумента(Документ);
    РепозиторийОстатков.ПроверитьНаличиеТоваров(Документ.Товары);
    ДвиженияДокументов.СформироватьДвижения(Документ);
КонецПроцедуры

Теперь каждая часть логики живёт в своём модуле, код легко читать и тестировать.

Инструменты для контроля качества

SonarQube для 1С помогает находить проблемы в коде: дублирование, сложные функции, нарушения стандартов.

EDT (Eclipse Development Tools) предоставляет более продвинутые возможности разработки по сравнению со стандартным конфигуратором.

Vanessa Automation позволяет писать автоматические тесты для проверки поведения системы.

Стандарты разработки от 1С и сообщества помогают поддерживать единый стиль кода в команде.

Когда стоит применять чистую архитектуру

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

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

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

Выводы

Чистая архитектура в 1С в классическом виде невозможна из-за особенностей платформы. Но применение принципов чистой архитектуры делает код понятнее, надёжнее и проще в поддержке.

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

Помните: цель архитектуры не в красивых диаграммах, а в том, чтобы код было легко понимать и изменять. Если ваш код решает эту задачу, вы на правильном пути.

Изучить основы архитектуры, паттерны проектирования и лучшие практики разработки в 1С можно в Кодике — нашей платформе для обучения программированию. Мы разбираем сложные темы простым языком, с примерами из реальной практики.

А ещё у нас есть крутой Telegram-канал с дружеским комьюнити разработчиков, где можно задать вопросы, поделиться опытом и найти единомышленников.
Присоединяйтесь!