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

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

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

Слои ShariX Open — границы владения данными и операциями, а не последовательность импортов всех приложений друг в друга. Для краткой навигации используйте карту источников; здесь описано, почему изменение относится к определённому владельцу.

• Orders, клиентские/корпоративные профили, Company, Service/Provider/Resource, Permissions/Relationship.
• Documents/DocumentVersion и definitions/checks/requirement rules.
• Scope метасервиса, канонические правила изменения и проверки actor/context.
• Чистые контракты вроде documents_core и integration ports для адаптеров.

Не добавляйте поле в синхронизируемую модель только ради локального интерфейса. Сначала определите, должен ли другой хост понимать его смысл и кто отвечает за изменение.

Ticket хранит тип/статус, участников, комментарии, вложения и события. Его состояние помогает маршрутизировать процесс, но не является доказательством успешной внешней операции или выполненного платежа. История документа и локальный результат этапа не переносятся в Ticket вместо своих моделей.

Событие после commit уведомляет владельца новой стадии; потерянная доставка не откатывает сохранённое состояние. Обработчик должен уметь перечитать канонический объект.

• OrdersLocal хранит локальные дополнительные данные и географические представления, связанные с Orders; это не второй общий Order.
• OrderExecution привязан OneToOne к Order и сохраняет execution-policy snapshot конкретного заказа.
• Stage — локальная единица исполнения со статусами PENDING/COMPLETED, правилами видимости и blocks_order_completion.
• Artifact, Correspondence и ExternalEvent имеют собственный execution context и проверку доступа.

Изменение design-time политики после создания заказа не должно молча менять сохранённый OrderExecution snapshot. Новый локальный этап или материал изменяется через owning execution service и его проверки, а не прямой подменой статуса заказа.

• Blockly workspace описывает явные действия/ветвления/ожидания; из него генерируется Python.
• handlers_backend предоставляет общий runtime, очередь/defer, transport и provenance.
• handlers_examples связывает runtime с каталогом ShariX Open и его настройками/путями.
• Narrow backend action сохраняет предметный результат; локальный reason/room и XMPP send не заменяют его.

Не прячьте новый workflow только в ручном generated Python и не переносите доменную модель в процессный буфер handler.

core.settings/core.urls определяют состав и маршруты сборки. AppConfig может зарегистрировать callback в backend-owned port: backend вызывает контракт, не импортируя web-layer ради discovery. Например, webservice_running регистрирует execution/verification adapters при готовности приложения.

Отсутствующий provider должен давать предусмотренное ограничение/ошибку, а не вымышленный успешный результат. Source checkout, Django runtime app, contribution manifest и фактический service result проверяются отдельно.

Service Constructor — закрытый компонент. Здесь обозначена только граница: общая система может потреблять согласованные определения/снимки через предусмотренный контракт, но внутренние модели и алгоритмы конструктора описываются во внутренней базе знаний. Подробности и доступ уточняются у ответственных Platform. Shared не означает открытую лицензию каждого расширения.

1. Назовите владельца новых данных и единственную каноническую операцию изменения.
2. Проверьте actor, объект, scope и возвращаемый результат.
3. Разделите изменяемую конфигурацию, snapshot действующего заказа и процессное ожидание.
4. Проверьте повтор/конкурентное действие и восстановление после неизвестного ответа.
5. При изменении shared опубликуйте код и передайте ответственному Platform для отдельной проверки/принятия.

Файлы, формы и названия слоёв подтверждают структуру исходников; успешная работа установки проверяется по критериям приёмки.

Проверено по Git-исходникам 31.10.2026. Состояние исходников отделено от состояния конкретной установки; команды ниже при редакционной проверке не выполнялись, бизнес-данные и значения секретов не читались.

• sharix-open-backend / models/orders.py.
• sharix-open-backend / models/documents.py.
• sharix-open-backend / lib/integration_ports.py.
• sharix-open-tickets / models/ticket.py.
• sharix-open-webservice-running / models/local_examples.py.
• sharix-open-webservice-running / models/execution.py.
• sharix-open-webservice-running / models/execution_extensions.py.
• sharix-open-webservice-running / apps.py.
• sharix-open-handlers-examples / runtime_provider.py.
• sharix-open-webapp-base / core/settings.py.
• sharix-open-webapp-base / core/urls.py.