Принятые архитектурные решения¶
Полный changelog решений с обоснованиями. Каждое решение зафиксировано для прозрачности.
| # | Решение | Обоснование |
|---|---|---|
| 1 | Проект — единица изоляции данных | Масштабирование через проекты |
| 2 | Модульная архитектура per-project | Разные проекты = разные инструменты |
| 3 | Contextual UI: отключённый модуль = скрыты все связанные элементы | Минимальная когнитивная нагрузка |
| 4 | 5 базовых шаблонов проектов (захардкожены) | Быстрый старт, пользовательские шаблоны — v2+ |
| 5 | Лиды, заявки, продажи = стадии воронки, не отдельные сущности | Deal-centric подход |
| 6 | Контакты создаются явно, не автоматически | Чистая база без мусора |
| 7 | Контакт ↔ Компания = many-to-many | Один человек может работать в нескольких компаниях |
| 8 | Сделка может быть на компанию или на контакт (физлицо) | Поддержка B2B и B2C |
| 9 | Воронка для сделок, этапы для продаж — разные механики | Продажа и исполнение разделены |
| 10 | Канбан доступен и для сделок (воронка) и для продаж (этапы) | Единый UX-паттерн |
| 11 | Продукт определяет тип продажи | Разные продукты = разные процессы оформления |
| 12 | Одна сделка → несколько продаж | Каждый продажа независим |
| 13 | Маркетинг убран в v1, заменён источниками сделок | Справочник + отчёт = 90% потребностей |
| 14 | Двухуровневые роли (системные + проектные) | Платформа vs проект |
| 15 | RBAC + иерархия отделов + шаринг | Гибкая видимость |
| 16 | Каждая запись ВСЕГДА привязана к владельцу (человек или отдел) | Нет «сиротских» записей |
| 17 | Шаринг доступа к отделу = виртуальное членство | Без переноса сотрудника |
| 18 | Флаг «Создание личных проектов» = только создание новых | Существующие проекты не затрагиваются |
| 19 | Биллинг личного и корпоративного пространства независим | Флаг управляет правами, не деньгами |
| 20 | Перелимит = read-only (grandfathering) | Данные не теряются |
| 21 | Грейс-период при неоплате: 7 дней | Мягкий подход |
| 22 | Удалённый сотрудник → проверка по каждому проекту отдельно | Руководителю если он в проекте, иначе «Требует переназначения» + уведомление Admin. Изоляция проектов не нарушается |
| 23 | Удалённый сотрудник → аккаунт = физлицо | Не блокирует человека |
| 24 | Передача между проектами = копируется ТОЛЬКО сделка | Продажи, продукты, активности, контакты, компании НЕ копируются. Полная матрица в 5.4 |
| 25 | Drawer — один, без вложенности, 6-8 полей max | Progressive Disclosure (аккордеон). Обогащение — в карточке |
| 26 | Проверка дублей при квалификации | По email, телефону, ИНН. Проверка и живых и удалённых записей |
| 27 | Merge с shadow-копией 30 дней, откат Admin+ | Защита от ошибок |
| 28 | Единый журнал аудита, два представления (per-entity, per-user) | Одна система, два фильтра |
| 29 | Аудит: CRUD + статусы + входы + merge + шаринг + передачи | Полная прозрачность |
| 30 | Аудит: иерархическая видимость (руководитель → подчинённые) | Согласованность с политиками доступа |
| 31 | Аудит: гибридное хранение (JSON Patch + абсолютные значения ключевых полей) | Patch для UI-diff, абсолютные значения для SQL-аналитики |
| 32 | Soft delete 7 дней → архив 6 мес → hard delete 1 год | Трёхступенчатый retention |
| 33 | Soft delete + unique index: проверка при создании И при восстановлении | Создание: предложить восстановить. Восстановление: если ключ занят → предложить Merge |
| 34 | Архивация проекта = read-only всех данных (включая продажаы) | Статусы фиксируются «как есть» |
| 35 | Массовые операции для Manager+ | Bulk actions без ада кликов |
| 36 | Импорт CSV/Excel (контакты, компании, продукты) | Миграция с других CRM |
| 37 | Конкурентное редактирование: last write + история (v1), live-editing v2+ | Минимальная сложность для v1 |
| 38 | Версионирование Order Type (schema_version) | Обратная совместимость |
| 39 | DLQ для финальных действий (retry + статус ошибки + редактирование полей) | Менеджер может исправить данные и повторить отправку |
| 40 | identity_hash для контактов и компаний (заложить в модель) | Нулевая стоимость сейчас, фундамент для Org Master Data v2+ |
| 41 | Stage log: полный лог входов на каждую стадию (включая возвраты) | Каждый вход = новая запись. Возврат не стирает историю. Фундамент для SLA v2+ |
| 42 | Переданная сделка → первая стадия воронки + метка + подсказка контактов | Система ищет совпадения по лёгким полям в целевом проекте |
| 43 | Self-hosted: заложить в архитектуру (Docker, абстракции), реализовать v2+ | Скорость разработки v1 |
| 44 | Drift Detection: снимок контакта/компании при привязке к сделке/продажау | Менеджер видит что данные изменились после привязки. Для продаж — Must Have (документы, webhook), для сделок — Should Have |
| 45 | Уведомления: in-app (колокольчик) + email, real-time через WebSocket/SSE | Критичные события (DLQ, перелимит, приглашения) не отключаются. Остальные настраиваются per-user |
| 46 | Активности: 4 типа (задача, звонок, встреча, заметка), привязка к любой сущности | Покрывает 90% потребностей менеджера. Повторяющиеся активности — v2+ |
| 47 | Дашборд: фиксированный набор виджетов, адаптивный по ролям и модулям | Настраиваемый дашборд — v2+. Contextual UI: виджеты скрываются при отключении модуля |
| 48 | Глобальный поиск по проекту (по подстроке, ≥ 2 символов) | Результаты группируются по типу сущности, макс. 5 на тип |
| 49 | Фильтры в URL (query params), сбрасываются при уходе. Сохранённые views — v2+ | Минимальная сложность для v1, фильтры шарятся через копирование URL |
| 50 | Запрет удаления стадий/воронок/типов продаж с активными данными | Сначала перемещение, потом удаление. Защита от потери данных |
| 51 | Документы: DOCX-шаблоны с переменными ({{entity.field}}), генерация по клику | Интеграция с Drift Detection: предупреждение если реквизиты изменились |
| 52 | Настройки пользователя: язык, timezone, формат даты. Хранение в UTC, конвертация на UI | Два языка в v1 (русский, английский). Последний вид (список/канбан) запоминается |