Перейти к содержимому

Код раскладывается по слоям с предсказуемыми точками входа:

  • Формы — только сбор параметров и отображение: без тяжёлых вычислений и без управления транзакциями (см. минимум серверных вызовов).
  • Прикладные сценарии — в общих модулях Сервер / СерверБезКонтекста с постфиксами по соглашению БСП (...Сервер, ...КлиентСервер, ...Глобальный).
  • Доменная логика объекта — в модуле объекта/менеджера (#std486), а не скопирована в каждую форму.
  • Интеграции (HTTP, файлы, внешние системы) — в отдельных модулях-адаптерах: остальной код зовёт адаптер, а не строит HTTP-запрос на месте.

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

flowchart TB
    F[Формы / команды] --> S[Прикладные сервисы<br/>общие модули Сервер]
    S --> D[Доменная логика<br/>модули объектов/менеджеров]
    S --> A[Адаптеры интеграций<br/>HTTP / файлы / БСП]
    S --> L[Логирование / ЖР]

Когда логика размазана по формам, каждая доработка начинается с археологии: где считается цена — в форме документа, в форме подбора или в обоих? Слои дают предсказуемость: подрядчик, впервые открывший конфигурацию, знает, где искать и куда класть. «Вызов сервера» на всех модулях подряд превращает внутренние функции в удалённое API, доступное любому клиентскому коду.

Для одноразовых внешних обработок полная слоистость избыточна — но и там интеграции и запросы не пишутся в модуле формы. Малым конфигурациям достаточно двух слоёв (формы + серверные общие модули) — важен принцип «форма тонкая, логика в модуле».