Перейти к содержанию

0005 — Доменная модель, доступ и данные

  • Дата: 2026-08-21.
  • Статус: Принято; пункт о закрытой регистрации заменён решением 0009.
  • Ответственный: владелец проекта.

Контекст

Frontend-прототип использовал демонстрационные данные без организации, сессий и устойчивых правил. Для безопасного вертикального MVP-среза требовалось определить минимальные сущности, tenant isolation и транзакционные инварианты до проектирования таблиц и endpoint-ов.

Решение

  • Бизнес-цепочка: User -> Membership -> Organization -> Client -> Request -> NextAction.
  • Пользователь потенциально может состоять в нескольких организациях; MVP показывает одну активную организацию.
  • Каждый NextAction принадлежит Request; активный Request имеет не более одного текущего незавершённого действия.
  • Быстрое добавление атомарно создаёт Client, Request, NextAction, AuditEvent и OutboxMessage.
  • today, overdue и later вычисляются из dueAt и обязательного часового пояса организации.
  • Каждая бизнес-таблица содержит organization_id; membership проверяется backend на каждом доступе.
  • Обычное удаление заменяется архивированием; аудит недоступен для обычного изменения.
  • Пилот не имеет открытой регистрации: организация создаётся администратором SKUARO, владелец получает email-приглашение. Этот пункт заменён решением 0009; остальные положения решения сохраняют силу.
  • Вход и recovery используют подтверждённый email; server-side sessions хранятся в PostgreSQL и выдаются через host-only secure cookie.
  • Архитектурные роли: owner, admin, member, viewer; первый MVP реализует только owner.

Причины

Модель выражает уже видимый пользовательский сценарий, но не превращает SKUARO в полную CRM. Обязательный organization_id, server-side membership check и транзакционная запись audit/outbox создают основу для безопасной многопользовательской эволюции без преждевременной реализации командных функций.

Последствия

  • Черновик Client, Request, NextAction в плане проверки заменён принятой моделью.
  • Прямой необязательный requestId у NextAction больше не допускается.
  • Телефон, дополнительные контакты и другая PII не добавляются без подтверждённой потребности.
  • Better Auth может обслуживать identity/session, но не владеет Organization и Membership.
  • Реальные клиентские данные запрещены до отдельной правовой, безопасностной и эксплуатационной проверки.

Откат или замена

Добавление сущностей или ослабление tenant-инвариантов требует нового решения и миграционного плана. Изменение набора полей внутри подтверждённой границы может оформляться схемой и контрактом без нового ADR.