C4 архитектура 1С: Эффективный Путь к Чёткой Документации

Модель представления архитектуры C4 (Context → Containers → Components → Code)

Работая с 1С, C4-схемы обычно рисуют в Confluence + diagrams.net / Draw.io, реже — в Miro или Visio.
Это не про инструмент, а про фиксацию архитектурных договорённостей в месте, где команда реально с ними работает

C4 Level 1 — System Context

Вопрос, на который отвечает:
👉 Где 1С находится в ландшафте и с кем она вообще взаимодействует?

Фиксирую границы системы:
что входит в зону ответственности 1С ERP,
какие системы являются внешними,
и какие типы взаимодействий между ними допустимы.

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

Типовая схема (словами)

В центре:
🟦 1С ERP (финансы, склад, договоры)

Вокруг:

• 🟩 Пользователи
  • бухгалтерия
  • финансы
  • логистика
  • экономисты
• 🟨 1С Бухгалтерия
• 🟨 1С ЗУП
• 🟨 BI / DWH
• 🟧 Магазины / POS
• 🟥 Самописная система (PHP / e-commerce)
• 🟦 Банки / платёжные сервисы
• 🟦 Корпоративные сервисы (НСИ, MDM)
• 🟦 Интеграционный шлюз / шина (если есть)

Стрелки:

• тип взаимодействия (онлайн / асинхрон / файлы)
• направление данных
• назначение (НСИ, документы, отчётность)

C4 Level 2 — Container Diagram

Вопрос, на который отвечает:
👉 Из каких логических частей состоит 1С ERP и как данные ходят внутри?

Пример контейнерного уровня для 1С ERP C4

🟦 Контейнеры внутри ERP (логические):

• Финансовый контур
  • бухгалтерия
  • налоговый учёт
  • БДР / ДДС
  • казначейство
• Склад / логистика
• Договорной контур
• НСИ
• Интеграционный слой
  • веб-сервисы
  • КД 2 / КД 3
  • файловые обмены
• Отчётность / аналитика
• Регламентные задания

🟧 Технические контейнеры:

• SQL Server
• Кластер серверов 1С
• Файловые хранилища (XML/XLSX)
• HTTP endpoints

Ты НЕ рисуешь объекты метаданных.
Ты рисуешь ответственности.

Один контейнер = одна зона ответственности и один тип нагрузки.

Ты отмечаешь где проходят границы ответственности внутри ERP:
что относится к финансовому учёту,
что к логистике,
что к интеграциям.

Это позволяет обсуждать изменения без “перетекания” логики между контурами.

C4 Level 3–4 почти никогда не нужны как постоянные артефакты, особенно в 1С-проектах.

C4 Level 3 — Component Diagram

Отвечает на вопрос:

Из каких логических компонентов состоит контейнер и как они взаимодействуют?

В 1С-контексте это:

• подсистемы,
• сервисные слои,
• интеграционные модули,
• границы ответственности кода.

⚠️ Это не список объектов метаданных.

---

C4 Level 4 — Code Diagram

Отвечает на вопрос:

Как устроен код внутри компонента?

В 1С это:

• модули,
• классы (если используешь ОО-подход),
• алгоритмы,
• вызовы процедур.

⚠️ Это уровень разработчика, не архитектора.

Нужны ли они реально в 1С-проектах?

Коротко

• L3 — иногда, точечно
• L4 — почти никогда

Почему так

🔹 1С — монолитная платформа

• Контейнер = конфигурация
• Компоненты быстро меняются
• Код тесно связан с метаданными

👉 Поддерживать актуальный L3/L4 как документацию — дорого и бессмысленно.

---

🔹 В 1С код — не источник архитектуры

В 1С:

• архитектура задаётся границами контуров и интеграций (L1–L2),
• детали реализации живут в коде и быстро устаревают.

👉 Документировать код поверх кода — проигрышная стратегия.

Когда C4 Level 3 всё-таки оправдан

✔ Реальные случаи (важно)

1️⃣ Сложный интеграционный слой

Например:

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

👉 Тогда L3 полезен, чтобы:

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

---

2️⃣ Выделенные подсистемы / фреймворки

Если ты делал:

• универсальный интеграционный фреймворк,
• слой сервисов,
• платформенные расширения,

👉 L3 помогает один раз зафиксировать устройство.

---

3️⃣ Разбор инцидентов или рефакторинг

Иногда L3 рисуют:

• в момент анализа проблемы,
• в момент проектирования изменений,

а потом… выбрасывают.

И это нормально.

Когда C4 Level 4 НЕ нужен (99% случаев)

C4 Level 4 в 1С как архитектурный артефакт не нужен, потому что это уровень реализации, который быстрее и точнее отражается в коде.

---

Как делаю я?

В своей практике я использую C4 Level 1–2 как основные архитектурные уровни.
Level 3 применяю точечно — для сложных подсистем или интеграционного слоя, когда нужно зафиксировать границы ответственности.

Level 4 как постоянную документацию не использую, потому что в 1С архитектура быстро устаревает на уровне кода, и надёжнее держать её в коде и правилах, а не в схемах.

Частые каверзные вопросы:

• Почему не документируете глубже?
  • Потому что цена поддержки такой документации выше её пользы.
• А как тогда передаёте знания?
  • Через код, code review, архитектурные принципы и точечные схемы там, где это действительно нужно.
• А если придёт новый разработчик?
  • Для него важнее понимать границы системы и правила интеграций (L1–L2),
  • а детали он читает в коде.

Архитектура — это про устойчивость системы,
а не про полноту документации.