Назначение: Архитектура. Продукт: ShariX Open · Общий компонент.

Для кого: Разработчик · Интегратор · Рецензент и приёмщик · Нейросеть.

Темы: Архитектура → Владение моделями · Архитектура → Границы.

Владелец модели — модуль, который определяет её смысл, структуру и разрешённые операции изменения. Если другой модуль использует эти данные, он обращается к существующей операции или хранит собственное расширение со ссылкой на общую запись. Так у одного бизнес-факта не появляются две независимые версии.

Список показывает ответственность. Точные имена классов и фактические связи проверяют по exports, моделям и миграциям нужной версии. У backend начальная точка — models/init.py. Для конкретной сущности читают:

• её модель;
• serializer;
• view;
• вызывающие функции.

Конструктор сервиса не относится к открытым модулям в таблице выше. В его LICENSE указана ShariX Proprietary License v1, код sharix-proprietary-v1. То, что модуль может устанавливаться вместе с ShariX Open или использоваться несколькими продуктами, не делает его открытым.

По проверенным лицензионным файлам тот же лицензионный код имеют следующие закрытые компоненты:

Это перечень проверенных компонентов, а не полный каталог всех закрытых модулей. Подробности находятся в intrawiki; за ними и согласованием доступа обращаются к ответственным со стороны Platform. Публичная страница может описать разрешённую точку подключения открытого ядра, но не переносит сюда устройство закрытого компонента.

Слово shared означает совместное использование модуля, а не открытую лицензию.

1. Назвать факт: что означает значение, кто его создаёт и меняет, кому оно нужно.
2. Проверить, не хранится ли тот же факт в открытой общей модели и не вычисляется ли уже из связанных данных. Если вопрос касается закрытого компонента, передать его ответственному; отсутствие доступа не компенсируют копированием его моделей в открытое ядро.
3. Если это общая семантика заказа, изменять её у владельца с проверкой потребителей. Если это особенность одного сервиса, рассмотреть его локальное расширение.
4. Для нового действия использовать или обоснованно расширить существующую операцию. Нельзя заменить её прямой записью статуса в случайном serializer.
5. Проверить прежние данные, миграции, права и отрицательные сценарии.

Внутри одной сборки допустим вызов опубликованной функции модуля, если направление зависимостей сохраняется. Для внешнего приложения используют предназначенный API или адаптер, а не прямую запись в его БД. Общая модель не должна импортировать локальную модель сервиса или код закрытого продукта, чтобы выполнить свою базовую операцию.

В webservice_running.models экспортируются две разные Django-модели:

• OrdersLocalFullTemplate — с полем order_synced;
• OrdersLocal из models/local_examples.py — с полем order.

Созвучные имена не делают их взаимозаменяемыми.

Перед изменением проверить:

• какой класс импортирует view;
• какие поля использует serializer;
• что сохранялось в БД.

Известное расхождение текущего локального API описано на странице Webservice Running. Исправление имени в одном месте без проверки остальных не подтверждает исправление операции.

• tickets.Event фиксирует тикетное событие; ExternalEvent относится к внешнему событию исполнения. Одно не заменяют другим по совпадению слова Event.
• Artifact принадлежит модулю исполнения. Nextcloud может хранить файл, но не становится владельцем бизнес-смысла артефакта.
• Сущность, извлечённая из документа, не становится автоматически Participant. Для участника нужны своё основание и предусмотренная операция.
• Функцию общего ядра не копируют в доменный модуль ради обхода её правил; локальную особенность не помещают в ядро без общей причины.

Правило владельца не запрещает развитие ядра ShariX Open. Перед таким изменением объясняют:

• требуемое поведение;
• затронутые API и приложения;
• совместимость сохранённых данных;
• переход существующей установки.

Наличие поля или успешный импорт не заменяют проверки поведения.

При разработке сторонней компанией учитывают LICENSE и COMPLIANCE конкретного репозитория и применимые требования к предоставлению исходников. Те же требования к осмысленности изменения и проверке действуют для внутренней разработки. Страница не заменяет лицензию компонента.

Общие (shared) модули ShariX Open могут использоваться и в Platform. После публикации изменения нужно оповестить ответственного со стороны Platform и передать:

• репозитории и commits;
• описание изменения;
• результаты проверки.

Ответственный проверяет изменение, тестирует его и оформляет принятие в общий код по своим инструкциям в intrawiki. Действия на Platform не выполняются как продолжение публичной инструкции ShariX Open.

Порядок передачи — shared-изменения. Связанные статьи: API, заказ и Ticket, репозитории.

Сверка исходников 28.10.2026: backend 57b98dc, webapp-base e795cd5, tickets fd64704. Карта ответственности согласована с публичным TZ: владельцы репозиториев. Лицензионные требования проверяются по версии конкретного компонента; source-сверка не является приёмкой установленной сборки.

Проверены опубликованные исходники указанных ревизий. Это source-анализ; он не подтверждает применённую версию, конфигурацию или успешный сценарий конкретного сервера.

• sharix-open-webapp-base: CODING_POLICY.md — f65376cdb5a3.
• sharix-open-backend: models/orders.py — 778a3280cee1.
• sharix-open-webservice-running: models/__init__.py — d5b966a88b2d.
• sharix-open-webservice-running: models/local_examples.py — d5b966a88b2d.
• sharix-open-webservice-running: models/webservice_running.py — d5b966a88b2d.

• sharix-open-backend: models/__init__.py.
• sharix-open-backend: models/orders.py.