Общие модули и слои — где живёт логика
Рекомендация
v8std#std469v8std#std486v8std#std679диагностикаCommonModuleNameClientServerдиагностикаCommonModuleNameServerCall
Рекомендация
Заголовок раздела «Рекомендация»Код раскладывается по слоям с предсказуемыми точками входа:
- Формы — только сбор параметров и отображение: без тяжёлых вычислений и без управления транзакциями (см. минимум серверных вызовов).
- Прикладные сценарии — в общих модулях
Сервер/СерверБезКонтекстас постфиксами по соглашению БСП (...Сервер,...КлиентСервер,...Глобальный). - Доменная логика объекта — в модуле объекта/менеджера (#std486), а не скопирована в каждую форму.
- Интеграции (HTTP, файлы, внешние системы) — в отдельных модулях-адаптерах: остальной код зовёт адаптер, а не строит HTTP-запрос на месте.
Признак «Вызов сервера» у общего модуля включается только там, где клиентский вызов действительно нужен (#std679). Модуль с «Вызов сервера» — это публичная поверхность клиент-серверного API: чем она шире, тем больше случайного трафика и поверхность атаки.
flowchart TB
F[Формы / команды] --> S[Прикладные сервисы<br/>общие модули Сервер]
S --> D[Доменная логика<br/>модули объектов/менеджеров]
S --> A[Адаптеры интеграций<br/>HTTP / файлы / БСП]
S --> L[Логирование / ЖР]
Когда логика размазана по формам, каждая доработка начинается с археологии: где считается цена — в форме документа, в форме подбора или в обоих? Слои дают предсказуемость: подрядчик, впервые открывший конфигурацию, знает, где искать и куда класть. «Вызов сервера» на всех модулях подряд превращает внутренние функции в удалённое API, доступное любому клиентскому коду.
Когда не применять
Заголовок раздела «Когда не применять»Для одноразовых внешних обработок полная слоистость избыточна — но и там интеграции и запросы не пишутся в модуле формы. Малым конфигурациям достаточно двух слоёв (формы + серверные общие модули) — важен принцип «форма тонкая, логика в модуле».