Введение: почему архитектура — это не «для больших компаний»
Есть распространённое заблуждение: архитектура прикладного решения нужна только на крупных внедрениях с десятками разработчиков. На практике всё наоборот — чем меньше команда, тем дороже обходится каждая архитектурная ошибка, потому что некому её вовремя заметить и никто не будет полгода «причёсывать» код после ухода автора.
1С как платформа даёт разработчику огромную свободу: можно положить бизнес-логику в модуль формы, можно — в общий модуль, можно вообще обойтись без модулей и сделать всё через события объекта. Платформа не заставляет соблюдать архитектурные границы — это забота разработчика и архитектора. Именно поэтому качество прикладного решения в 1С различается драматически: от конфигураций, которые можно поддерживать десятилетиями, до систем, где боятся трогать любую строчку кода.
В этой статье разберём практические принципы построения архитектуры прикладных решений на 1С: работу с данными, слоистость кода, отчётность и дашборды, интеграционную архитектуру и типичные ошибки.
1. Архитектура данных: фундамент, который потом не переделать
Регистры vs справочники: выбор модели хранения
Первая и самая важная развилка — как хранить факты хозяйственной деятельности. Новички часто злоупотребляют справочниками там, где нужны регистры сведений или накопления, и наоборот.
Правило простое: если сущность отвечает на вопрос «сколько» или «что произошло в момент времени T» — это регистр. Если сущность отвечает на вопрос «что это за объект» и обладает собственным жизненным циклом (создание, редактирование, пометка удаления) — это справочник или документ.
Типичная ошибка — создание справочника «Остатки на складе» с полем «Количество», которое обновляется вручную при каждой отгрузке. Это разрушает саму идею регистра накопления, ради которой в платформе существуют механизмы итогов, виртуальные таблицы остатков и оборотов, оптимизированные под параллельную запись. Через год-два в такой конфигурации начинаются блокировки таблиц при одновременном проведении документов, и «починить» это без миграции данных уже нельзя.
Нормализация против производительности
Классическая нормализация (3НФ) снижает избыточность, но в учётных системах с миллионами записей чистая нормализация часто проигрывает денормализованным структурам, оптимизированным под чтение. Регистры бухгалтерии и накопления в 1С — это, по сути, управляемая денормализация: платформа хранит итоги отдельно от движений именно для того, чтобы не пересчитывать агрегаты «на лету».
Практический вывод для архитектора: при проектировании собственных подсистем стоит заранее решить, что важнее — скорость записи или скорость чтения, — и осознанно выбирать между «регистром с движениями» и «таблицей итогов, пересчитываемой по расписанию». Попытка одной структурой данных обслужить оба сценария почти всегда заканчивается компромиссом, который не устраивает никого.
Управление ссылочной целостностью
Ссылки в 1С не имеют полноценных внешних ключей на уровне СУБД — целостность обеспечивается платформой на уровне метаданных и лишь частично контролируется при удалении (стандартный контроль ссылочной целостности). Это значит, что архитектор обязан явно продумать:
- Что происходит при пометке удаления справочника, на который ссылаются регистры сведений периодического характера?
- Нужен ли механизм «мягкого» удаления с пометкой недействительности вместо физического?
- Как обрабатывать ситуацию, когда справочник помечен на удаление, но по нему есть исторические движения за прошлые периоды, которые нельзя менять по регламенту?
Отсутствие продуманной политики здесь — одна из самых частых причин «зависших» объектов, которые нельзя ни удалить, ни восстановить корректно.
2. Слоистость прикладного кода
Проблема «толстых» модулей форм
Самая распространённая архитектурная болезнь типовых и самописных конфигураций — бизнес-логика, размазанная по модулям форм. Обработчик ПередЗаписью на форме документа, в котором происходит расчёт себестоимости, проверка остатков и формирование движений, — гарантированный источник дублирования кода, потому что та же логика неизбежно понадобится в фоновом задании, в обработке группового изменения реквизитов или в обмене данными, где форма вообще не открывается.
Рабочий подход — трёхслойная модель:
- Слой представления — формы, командный интерфейс, элементы управления. Только вызов методов нижнего слоя и обработка результата для пользователя.
-
Слой бизнес-логики — общие модули с методами, не зависящими от интерфейса (МодульДокументаЗаказПокупателяСервер, РаботаСЗаказамиСервер и т.п.). Именно сюда выносится расчёт, проверка условий, формирование движений.
- Слой данных — методы работы с объектами метаданных, запросы, обёртки над характерными операциями с базой.
Такое разделение не панацея само по себе, но оно даёт главное — возможность вызвать бизнес-логику из любого контекста: интерфейса, фонового задания, обмена, обработчика подписки на событие, — не копируя код.
Общие модули: границы ответственности
Ещё одна типичная проблема — общий модуль-«помойка», куда попадает всё подряд, потому что «а куда ещё». Через два года в таком модуле пять тысяч строк, и никто не знает точно, какие процедуры используются, а какие остались от давно удалённого функционала.
Практика, которая реально работает: называть общие модули по предметной области, а не по техническому назначению («РаботаСДоговорами», а не «ОбщегоНазначения2»), и явно фиксировать в комментарии к модулю его зону ответственности и точки входа, которые считаются публичным API модуля, — остальные процедуры помечать как внутренние и не вызывать извне.
Расширения vs изменение конфигурации
С появлением расширений архитектурный выбор «дорабатывать типовую напрямую или через расширение» стал одним из ключевых решений на старте проекта. Расширения снижают стоимость обновлений типовых конфигураций, но накладывают ограничения: не весь функционал можно реализовать через расширяемые объекты, а чрезмерное количество расширений от разных подрядчиков создаёт свою собственную сложность — конфликты приоритетов подписок на события, пересекающиеся адаптации одних и тех же форм.
Архитектору стоит заранее определить политику: например, «расширения — для локальных доработок под конкретный участок учёта, изменения ядровой логики документооборота — только в основной конфигурации с фиксацией отличий от типовой в отдельном документе».
3. Отчётность и дашборды: архитектура для аналитики, а не для одной формы
СКД как архитектурный инструмент, а не просто конструктор отчётов
Система компоновки данных часто воспринимается разработчиками как удобный способ быстро собрать отчёт, но с архитектурной точки зрения СКД — это способ отделить логику получения данных (набор данных, запрос, связи наборов) от логики представления (структура отчёта, группировки, оформление). Если эти два слоя перепутать — например, зашить фильтрацию по правам доступа прямо в текст запроса конкретного отчёта — та же логика прав придётся продублировать в следующем отчёте по той же теме.
Правильная практика — выносить часто используемые фрагменты запроса (например, проверку прав на просмотр данных по организациям или подразделениям) в отдельные представления или временные таблицы, переиспользуемые между разными отчётами, а не копировать текст запроса из отчёта в отчёт.
Аналитические витрины вместо «больших» запросов на лету
Когда отчёт должен агрегировать данные за несколько лет или строить сложную аналитику по многим измерениям, прямой запрос к регистрам «на лету» рано или поздно упирается в производительность, особенно при одновременной работе большого числа пользователей. Архитектурное решение — регламентное построение аналитических витрин: отдельных регистров сведений или таблиц, куда данные агрегируются по расписанию, а отчёты и дашборды читают уже готовые агрегаты.
Это классический компромисс между актуальностью данных (витрина обновляется не мгновенно) и скоростью отображения. Важно явно проговорить с заказчиком эту границу: дашборд для операционного контроля должен строиться на реальном времени, дашборд для стратегической аналитики вполне может обновляться раз в час или раз в сутки — и это нормально, если зафиксировано заранее, а не выясняется в момент, когда цифры «не сошлись».
Место BI-инструментов и внешних дашбордов
Отдельный архитектурный вопрос — строить дашборды средствами самой 1С (диаграммы на управляемых формах, отчёты СКД с оформлением) или выгружать данные во внешние BI-системы. Здесь нет универсально правильного ответа: если аналитика нужна только пользователям учётной системы и не требует объединения данных из нескольких источников — достаточно встроенных средств. Если нужна консолидация данных из CRM, складской системы и 1С в одном дашборде для руководства — целесообразнее регулярная выгрузка в BI-инструмент через API или через промежуточное хранилище.
Ключевая архитектурная рекомендация — заранее спроектировать формат и контракт выгрузки (какие поля, с какой периодичностью, в каком виде идентифицируются объекты) как отдельный, версионируемый интерфейс, а не как побочный продукт текущей структуры базы, которая может измениться при следующем обновлении.
4. Интеграционная архитектура
Точки интеграции как часть модели данных
Любая система, которая обменивается данными с внешними сервисами (сайтом, маркетплейсом, банком, другой учётной системой), должна с самого начала проектироваться с явными точками интеграции — а не «прикручиваться» постфактум через прямые запросы к таблицам регистров.
Практический принцип: для каждого внешнего контура заводится собственный слой обмена — либо через стандартные механизмы (планы обмена, EnterpriseData, HTTP-сервисы), либо через промежуточные таблицы очереди сообщений. Это позволяет не привязывать бизнес-логику к конкретному протоколу обмена и безболезненно менять способ интеграции (например, переходить с прямого HTTP-вызова на очередь сообщений при росте нагрузки), не переписывая саму бизнес-логику.
Идемпотентность и повторная обработка
В распределённых интеграциях сообщения дублируются, теряются или приходят с задержкой — это данность, а не исключительная ситуация. Архитектура обмена данными в 1С должна закладывать идемпотентность обработки: повторное получение уже обработанного сообщения не должно приводить к задвоению документов или движений. Обычно это реализуется через хранение внешних идентификаторов сообщений и проверку «уже обработано ли это сообщение» перед созданием объектов.
Асинхронность и фоновые задания
Синхронные вызовы внешних сервисов из обработчиков проведения документов — частая причина зависаний интерфейса и таймаутов при недоступности внешней системы. Архитектурно правильнее выносить взаимодействие с внешними сервисами в фоновые и регламентные задания, а бизнес-процессу пользователя оставлять постановку задачи в очередь и, при необходимости, асинхронное уведомление о результате.
5. Типичные архитектурные ошибки и как их избежать
Обобщая практику внедрений, можно выделить несколько повторяющихся ошибок:
- Отсутствие единой точки входа для критичной бизнес-логики. Расчёт себестоимости, ценообразование, проверка кредитных лимитов реализуются в нескольких местах с небольшими отличиями — и со временем логика расходится.
- Игнорирование прав доступа на уровне архитектуры данных. Проверка прав «размазывается» по формам и отчётам вместо того, чтобы быть частью универсального механизма фильтрации данных.
- Смешение слоя интеграции и слоя учёта. Внешний формат обмена становится внутренней структурой данных, и любое изменение формата партнёра ломает учётную систему.
- Отсутствие версионирования доработок. Изменения типовой конфигурации не документируются отдельно от истории версий, что делает обновления крайне рискованными.
- Излишняя генерализация. Попытка сделать «универсальный» механизм под все будущие случаи усложняет систему сильнее, чем набор специализированных, но понятных решений под конкретные задачи.
Заключение
Архитектура прикладного решения в 1С — это не про красивые UML-диаграммы, которые никто потом не откроет, а про набор осознанных решений: как хранить данные, где живёт бизнес-логика, как разделены слои представления и данных, как устроена аналитика и как система разговаривает с внешним миром. Каждое из этих решений имеет свою цену, и задача архитектора — сделать эту цену явной и обсуждаемой на старте проекта, а не обнаруживать её постфактум в виде тормозящих отчётов, дублирующегося кода и конфигурации, в которую страшно вносить изменения.
Хорошая архитектура не избавляет от доработок — она делает так, чтобы каждая следующая доработка была немного проще предыдущей, а не наоборот.