Направление работ: Back Код раздела: 1.1 Аккаунты и пользователи > Организация аккаунтов Статус: на валидации Ответственный: Панкова Л.А. Версия: 0.3 Обновлено: 04.09.26
1. Назначение
Организация аккаунтов задает общую модель Аккаунтов в системе: связь с Карточкой клиента, матрицу состояний Аккаунта, учетные данные, тариф и права доступа.
Система хранит аккаунты и общие ограничения, которые используют процессы регистрации, входа, восстановления доступа и дополнительных способов входа.
2. Ключевые понятия
Аккаунт — централизованная сущность пользователя. Хранит учетные данные, состояние и выданные доступы.
Карточка клиента — сущность для хранения персональной информации об аккаунте, истории заказов и отношений с партнерами.
Состояние Аккаунта — положение учетной записи в матрице состояний. Складывается из трех признаков и только из них: существует ли запись, полон ли профиль и есть ли действующая связь с партнерской зоной. Авторизация в состояние не входит: один и тот же Аккаунт бывает неавторизованным, открытым в мобильном приложении или открытым в кабинете партнера — состояние при этом одно и то же.
Полнота профиля — заполненность набора данных, обязательного для самостоятельной регистрации в партнерском приложении: номер телефона, имя, фамилия и email. Учитывается заполненность, а не подтвержденность: подтверждение email — отдельный признак с отдельной ролью, им завершается Приглашение.
Связь с партнерской зоной — наличие хотя бы одной действующей записи сотрудника: владельца или работника. Архивные записи связью не считаются. Сервисные роли в матрицу состояний не входят: сотрудник сервиса — не связь с партнерской зоной.
Приглашение — заведение Аккаунта третьим лицом, владельцем партнерской зоны, по одному номеру телефона. Приглашение считается завершенным, когда приглашенный дозаполнил профиль и подтвердил email; до этого назначенные роли не действуют.
Заблокированный аккаунт — аккаунт, заблокированный в системе. Блокировка в матрицу состояний не входит: она ограничивает вход, а не положение Аккаунта.
Токен доступа — технический ключ, который подтверждает, что аккаунт прошел аутентификацию, и позволяет системе выполнять запросы от имени этого аккаунта. В системе используются два типа токенов: краткосрочный access token для доступа к API и долгосрочный refresh token для получения нового access token без повторного входа.
Учетные данные — данные для входа в Аккаунт. Обязательные: номер телефона, пароль, Email для партнерской зоны. Необязательные: уникальный логин, Email для клиентской зоны.
3. Scope
Входит
S1: Аккаунт
- Схема данных.
- Связь Аккаунта и Карточки клиента.
- Матрица состояний Аккаунта: состояния, переходы между ними и инварианты.
- Ограничения действий по состояниям.
S2: Валидация и ограничения
- Общие правила хранения и проверки учетных данных.
- Общие лимиты попыток подтверждения и ввода учетных данных.
- Общая защита от ботов и DDoS-атак.
Не входит
- Регистрация как процесс — Back: 1.1.1
- Вход в систему — Back: 1.1.2
- Восстановление доступа — Back: 1.1.3
- Дополнительные способы регистрации и входа — Back: 1.1.4
- Бизнес-логика Карточки клиента и партнерских данных клиента — Back: 1.3
- Партнерская зона и ее настройки — Back: 1.4.1
4. Состояния Аккаунта
Матрица состояний — источник истины о положении учетной записи. Состояние собирается системой и отдается потребителю готовым значением; собирать его на стороне клиента из признаков архивности, подтверждения почты и списка ролей не следует — собранное по-разному, оно разойдется между приложениями при первом же уточнении правил.
Состояние определяется тремя признаками и только ими:
| Признак | Значение |
|---|---|
| Существование Аккаунта | учетной записи нет, она активна или архивирована |
| Полнота профиля | заполнены номер телефона, имя, фамилия и email — либо заполнен только номер телефона |
| Связь с партнерской зоной | есть хотя бы одна действующая связь владельца или работника — либо связей нет |
4.1 Состояния
| Код | Состояние | Описание |
|---|---|---|
| S1 | Не зарегистрирован | Аккаунта с данным номером телефона в системе нет. Начальное логическое состояние, а не сохраненная запись. |
| S2 | Зарегистрирован неполностью | Активный Аккаунт с номером телефона, но без полного набора персональных данных. Обычное состояние регистрации из мобильного приложения. Действующей связи с партнерской зоной нет. |
| S3 | Зарегистрирован полностью | Активный Аккаунт с номером телефона, именем, фамилией и email. Действующей связи с партнерской зоной нет. |
| S4 | Неполный профиль, есть партнерская зона | Активный Аккаунт с неполным профилем и действующей связью с партнерской зоной. Так выглядит приглашенный сотрудник: роли назначены, но не действуют. До дозаполнения данных и подтверждения email пользователь не получает доступ в кабинет партнера. |
| S5 | Полный профиль, есть партнерская зона | Активный Аккаунт с полным профилем и действующей связью с партнерской зоной. Единственное состояние, из которого открывается кабинет партнера — в пределах назначенной роли. |
| S6 | Архивирован | Учетная запись архивирована, работа во всех партнерских зонах убрана в архив. Полнота профиля сохраняется: по ней при восстановлении определяется целевое состояние — S2 или S3. |
4.2 Переходы
| Код | Из | Событие | В |
|---|---|---|---|
| A | S1 | Регистрация через мобильное приложение только по номеру телефона | S2. Создается неполный Аккаунт и Карточка клиента. |
| B | S1 | Самостоятельная регистрация в кабинете партнера с полными данными, без создания или назначения партнерской зоны | S3 |
| C | S1 | Владелец партнерской зоны добавляет будущего работника по номеру телефона | S4. Создается неполный Аккаунт, Карточка клиента и связь с партнерской зоной. |
| D | S2 | Пользователь заполняет имя, фамилию и email в мобильном приложении | S3 |
| E | S2 | Владелец партнерской зоны назначает пользователя будущим работником | S4 |
| F | S2 | Пользователь архивирует учетную запись | S6 |
| G | S3 | Пользователь архивирует учетную запись | S6 |
| H | S3 | Владелец партнерской зоны назначает пользователя работником | S5. Повторная регистрация в кабинете партнера не требуется. |
| I | S4 | Пользователь дозаполняет имя, фамилию и email в кабинете партнера и подтверждает email | S5. Приглашение завершено, назначенные роли начинают действовать во всех зонах разом. |
| J | S5 | Последняя действующая связь с партнерской зоной прекращается, например при увольнении | S3 |
| K | S5 | Пользователь архивирует учетную запись | S6 |
| L | S6 | Восстановление учетной записи с неполным профилем | S2. Связи с партнерскими зонами не восстанавливаются. |
| M | S6 | Восстановление учетной записи с полным профилем | S3. Связи с партнерскими зонами не восстанавливаются. |
| N | S4 | Пользователь архивирует учетную запись | S6 |
| O | S4 | Последняя связь с зоной прекращается у приглашенного, который успел войти | S2. Аккаунт живет: человек им пользуется, и зона им не распоряжается. |
| P | S4 | Последняя связь с зоной прекращается у приглашенного, который не входил ни разу | S6. Аккаунт заводился приглашением и не пригодился — отзывается вместе со связью. |
Переходы O и P различаются одним признаком — подтвержденным номером телефона. Подтверждает его первый же вход, а войти приглашенный может только временным паролем из приглашения. Неподтвержденный номер означает, что учетной записью никто не пользовался: она заведена зоной и принадлежит зоне. Смысл перехода P — исправимость ошибки: ошибись владелец в одной цифре номера, тот навсегда остался бы занят пустой записью, и завести на него сотрудника заново стало бы нельзя.
4.3 Невозможные переходы
- S6 → S4 и S6 → S5: архивирование убирает связи с партнерскими зонами в архив, и автоматически они не восстанавливаются.
- S6 → S6: повторная архивация — не событие, а повторенная команда, и отвечать на нее следует отказом.
- S3 → S2 и S5 → S4: заполненные данные не стираются.
- Возврат в S1 из любого состояния: удаление ведет в S6, а не в «не зарегистрирован».
Переход в себя законен у живых состояний: событие бывает и настоящим, и ничего не меняющим — владелец завел сотрудника тому, у кого зона уже есть, и S5 осталось S5.
4.4 Инварианты
- Полный профиль содержит номер телефона, имя, фамилию и email; неполный содержит номер телефона.
- Наличие связи с партнерской зоной означает роль владельца или работника хотя бы в одной зоне.
- «Разрыв связи с зоной» означает архивирование записи сотрудника, а не ее удаление. Запись остается: по ней видно, где человек работал, на ней держатся его роли, и по ней же его зовут обратно — повторное заведение поднимает архивную запись. Архивируется она тем же способом, каким владелец зоны увольняет работника; разница только в охвате — архивация Аккаунта снимает человека со всех зон разом.
- У каждого живого Аккаунта есть Карточка клиента. Она заводится вместе с учетной записью во всех трех путях регистрации — A, B и C — и не требует имени: Аккаунт создается по одному номеру телефона, и Карточка тоже.
- Архивированный Аккаунт не имеет действующих связей с партнерскими зонами.
- Восстановление Аккаунта, у которого осталась действующая запись сотрудника, отклоняется: это означает, что архивация инвариант не соблюла.
Полное техническое описание автомата с местами переходов в коде ведется в монорепозитории бэкенда: docs/access-control/account-state-machine.md.
5. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Требования | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: BR1.1-1 | Аккаунт хранит только учетные данные, состояние и выданные доступы. | Персональные данные, история заказов, отношения с партнерами и CRM-данные хранятся в Карточке клиента. | Техническое | 1 | Реализовано |
| S1: BR1.1-2 | Аккаунт не может существовать без связанной Карточки клиента. | Одна карточка клиента не может быть связана с несколькими активными аккаунтами, и один активный аккаунт не может быть связан с несколькими карточками. Карточка заводится вместе с Аккаунтом во всех трех путях регистрации и не требует имени: Аккаунт создается по одному номеру телефона, и Карточка тоже. Инвариант держится сверкой — расхождение исправляется без участия человека. Карточка клиента и ее связь с аккаунтом описана в https://wiki.yandex.ru/homepage/d750da42741c/texnicheskaja-dokumentacija/brd/dokumentacija-po-funkcionalurazdelam/1-akkaunty-i-polzovateli/1.3-klienty/ | Системное | 1 | OQ1.1-2 Реализовано |
| S1: BR1.1-3 | Аккаунт может находиться только в одном из состояний матрицы состояний: S1–S6. | Состояние складывается из трех признаков и только из них: существование записи, полнота профиля, связь с партнерской зоной. Авторизация в состояние не входит. Кабинет партнера открывается только в S5. Блокировка в матрицу не входит: заблокированные не могут войти в систему, восстановить доступ могут через службу поддержки. | Бизнес | 1 | Реализовано |
| S1: BR1.1-4 | Для аккаунта доступны архивирование и восстановление | Архивирование переводит Аккаунт в S6 из любого живого состояния — переходы F, G, N, K. Восстановление возвращает Аккаунт в S2 или S3 по сохраненной полноте профиля — переходы L и M. Связи с партнерскими зонами при этом не восстанавливаются. Восстановление происходит в результате регистрации https://wiki.yandex.ru/homepage/d750da42741c/texnicheskaja-dokumentacija/brd/dokumentacija-po-funkcionalurazdelam/1-akkaunty-i-polzovateli/1.1-organizacija-akkauntov-v-sisteme/1.1.1-registracija/ | Бизнес | 2 | Реализовано OQ1.1-10 |
| S1: BR1.1-5 | Для создания Аккаунта из учетных данных является обязательным только номер телефона и пароль. | Бизнес | 1 | Реализовано | |
| S2: BR1.1-6 | Аккаунт после удаления хранится в течение 5 лет. | После истечения 5 лет все данные из связанной карточки клиента удаляются. | Бизнес | 2 | Частично реализовано OQ1.1-14 |
| S2: BR1.1-7 | В рамках организации Акаунтов учетные данные являются уникальными кроме пароля. | Системное | 1 | OQ1.1-3 Частично реализовано | |
| S2: BR1.1-8 | Email и телефон должны подтверждаться 6-ти значным кодом. | Системное | 1 | Реализовано | |
| S2: BR1.1-9 | Код должен иметь ограниченный срок действия, ограниченное число попыток ввода и ограничение на повторную отправку. | Системное | 1 | OQ1.1-5 Частично реализовано | |
| S2: BR1.1-10 | Система предусматривает и ограничивает количество попыток подтверждения учетных данных. | Таймаут применяется к подтверждению телефона, email. | Системное | 2 | OQ1.1-6 Частично реализовано |
| S2: BR1.1-11 | Система ограничивает количество попыток ввода учетных данных. | При превышении лимита дальнейшие действия временно блокируются. | Системное | 2 | Не реализовано |
| S2: BR1.1-12 | Для поддержки используются 2 токена: долгосрочный для аутентификации и краткосрочный для автообновление долгосрочного. | Для мобильного приложения 2 недели Для партнерской и админский зон 24 часа | Техническое | 3 | OQ1.1-7 Частично реализовано |
| S2: BR1.1-13 | Система поддерживает несколько активных сессий и позволяет избегать повторной авторизации в течение длительного периода. | Бизнес | 3 | Не реализовано | |
| S1: BR1.1-14 | Архивация Аккаунта должна убирать в архив его работу во всех партнерских зонах. | Записи сотрудника архивируются тем же способом, каким владелец зоны увольняет работника; разница только в охвате. Записи не удаляются: по ним видно, где человек работал, и по ним же его зовут обратно. Без этого восстановленный Аккаунт молча оказался бы снова работником, которого зона считает уволенным. | Системное | 1 | Реализовано |
| S1: BR1.1-15 | Приглашение на номер архивного Аккаунта должно отклоняться. | Номер архивного Аккаунта система считает свободным при проверке уникальности, поэтому проверка обязана быть явной: без нее заведение сотрудника уходило бы по ветке «номер незнаком» и создавало второй Аккаунт на тот же номер. Человек восстанавливает учетную запись сам — повторной регистрацией. | Бизнес | 1 | Реализовано OQ1.1-12 |
| S1: BR1.1-16 | Восстановление Аккаунта не должно восстанавливать связи с партнерскими зонами. | Переходы S6 → S4 и S6 → S5 невозможны. Если у архивного Аккаунта осталась действующая запись сотрудника, восстановление отклоняется: это означает, что архивация инвариант не соблюла. | Системное | 1 | Реализовано |
| S1: BR1.1-17 | Прекращение последней связи с партнерской зоной у приглашенного, который ни разу не входил, должно архивировать его Аккаунт. | Переход P. Приглашенный, успевший войти, при увольнении остается жить и переходит в S2 — переход O. Признак «не входил ни разу» — неподтвержденный номер телефона: подтверждает его первый вход по временному паролю из приглашения. Смысл правила — исправимость ошибки в номере: иначе ошибочно набранный номер навсегда остался бы занят пустой записью. | Бизнес | 1 | Реализовано |
| S1: BR1.1-18 | Система должна отдавать состояние Аккаунта готовым значением. | Потребителю не следует собирать состояние самому из признаков архивности, подтверждения email и списка ролей: собранное на стороне клиента, оно разойдется между приложениями при первом же уточнении правил. Вместе с состоянием отдается признак подтверждения email — по состоянию «email введен, код не подтвержден» и «все готово» неразличимы. | Системное | 1 | Реализовано |
6. Открытые вопросы
Пин контекста (повторная/дельта сверка). BRD: версия 0.3, обновлено 04.09.26. Код:
booking-monorepo, commit82359296(2026-09-07), read-only detached worktree наorigin/main. Дата сверки: 2026-09-08. Якорь:src/services/booking.authentication(cross-service точки проверены точечно:booking.clients,booking.apigateway). Гайдбук не передан — маршрутизация без сверки с гайдбуком. Старые статусы и вопросы (OQ1.1-1…OQ1.1-12) — результат предыдущей сверки; их текст, «Кому», «Статус», «Рекомендации» и «Итоговое решение» не менялись, перепроверялся только код под каждое требование.
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ1.1-1 | Код Б3 | Код: уникальность телефона/email при проверке включает АРХИВНЫЕ аккаунты (фильтр IsArchived закомментирован) — архивный аккаунт блокирует повторную регистрацию того же телефона/email. В BRD 1.1 (S2, уникальность учетных данных) поведение для архивных не оговорено.Решение: должен ли архивный аккаунт «держать» телефон/email или они должны освобождаться? | Бизнес | Open | Внесено в БРД тут и в 1.1.1 и 1.1.3 | |
| OQ1.1-2 | Код П1 | Код: связь реализована как соглашение по совпадению Id (Account.Id = clientId ?? Guid.NewGuid()), карточка создаётся асинхронно через AccountCreatedEvent; 1:1 НЕ enforce-ится FK/unique-индексом в этой БД. Расхождение: гарантия 1:1 декларативная, не структурная.Где должна enforce-иться целостность 1:1? |RegistrationMobileEndCommandHandler.cs:85,106-167; relationships Account↔Client (cross-service, confidence medium)| | Разработка | Closed | ||
| OQ1.1-3 | Код П2 | Код: уникальность телефона/email обеспечивается ТОЛЬКО проверкой в коде, без unique-индекса в БД (RequireUniqueEmail не задан; в миграциях unique только на normalized_username(случайный Guid), normalized_name(роли), invite_code). При гонке возможны дубли телефона/email на уровне БД.Расхождение: «уникальность» не гарантирована БД. Достаточно ли проверки в приложении или нужен constraint? |SendRegistrationCodeMobileCommandHandler.cs:51-55; AccountRepository (нет unique-индекса phone/email); ProgramExtenstions.cs:203-212| | Разработка | Open | Техдолг: сделать либо через событие или проверку кэша Вес: 3 | |
| OQ1.1-4 | Код П3 | Код: подтверждение телефона при регистрации есть (SendVerifyCode/VerifyCode-хендлеры), но при ВХОДЕ по email EmailConfirmed не проверяется (см. 1.1.2), а проверка наличия почты при сбросе игнорирует EmailConfirmed.Частично: код подтверждения существует, но «подтверждённость email» не enforce-ится на всех путях. Должен ли email везде использоваться только подтверждённым? |SendRegistrationCodeMobileCommandHandler.cs:57-80; AccountRepository.cs:139-143| | Разработка | Open | Перенести во вход Вес: 2 | |
| OQ1.1-5 | Код П4 | Код: ограничение на повторную ОТПРАВКУ есть в Widget/LK (rate-limit), но в МОБИЛЬНОЙ регистрации SendRegistrationCodeMobileCommandHandler НЕ вызывает rate-limiter вообще (есть только TTL кэша); ограничения на число попыток ВВОДА кода нет.Частично: срок жизни и часть лимитов есть, число попыток ввода и повторная отправка в Mobile — не покрыты. RateLimitPolicy.cs:54-77; SendRegistrationCodeMobileCommandHandler.cs (нет вызова rateLimiter)| | Разработка | Open | Доделать эндпоинт для моб IdentityService/SendRegistrationCodeMobile | |
| OQ1.1-6 | Код П5 | Код: rate-limit на отправку кодов есть в части потоков, но «ограничение числа попыток подтверждения» (ввода кода) как отдельный механизм не найдено за обход; в Mobile-регистрации лимита на отправку кода нет. Частично/не найдено за обход. RateLimitPolicy.cs:54-77; SendRegistrationCodeMobileCommandHandler.cs | Разработка | Open | Доделать эндпоинт для моб IdentityService/SendRegistrationCodeMobile | |
| OQ1.1-7 | Код П6 | Код: refresh-токен — случайные 32 байта, отдельного срока жизни refresh нет; ExpiresAt сессии = срок access-токена. Расхождение: (1) «долгосрочности» refresh отдельным lifetime не подтверждено; (2) формулировка BRD инвертирована (краткосрочный обновляет долгосрочный) относительно обычной модели.Какой целевой lifetime у refresh? AccountSession.cs:14; not_found (refresh lifetime) | Разработка | Open | Рефреш: месяц для моб / сутки для партнерши и админки Вес: 3 | |
| OQ1.1-8 | Код | BRD: Scope S2 заявляет «общую защиту от ботов и DDoS-атак». Код: captcha/recaptcha/bot/ddos в якоре не найдено за обход; rate-limit только per-account/per-phone. Может жить в apigateway/инфраструктуре — за пределами якоря не проверялось. Где реализована защита от ботов/DDoS? grep captcha/bot/ddos — не найдено за обход; DistributedRateLimiter.cs | Разработка | Closed | Важна для сайта и виджета, лежит в другом слое: Back 10.4 Безопасность системы Индепатенция? | |
| OQ1.1-9 | Код | Требование говорит: учетные данные уникальны (BR1.1-7). В коде уникальный индекс на пару phone_number + country_code в базе отсутствует: логическая уникальность номера держится только проверкой в приложении, и эта проверка считает номер архивного Аккаунта свободным. При гонке возможны два живых Аккаунта на один номер.Нужен ли уникальный индекс среди неархивных записей? | Разработка | Open | Продолжение OQ1.1-3 — там тот же разрыв про email. Завести один тикет на оба: частичный уникальный индекс WHERE is_archived = false по паре «номер + код страны» и по email. | |
| OQ1.1-10 | Код | Требование говорит: для Аккаунта доступно восстановление (BR1.1-4). В коде путей восстановления два: повторная регистрация тем же номером поднимает архивный Аккаунт, а отдельная команда восстановления помечена как неиспользуемая. Фактически работает первый путь. Оставляем два пути или сводим к одному? | Разработка | Open | Свести к одному: восстановление через повторную регистрацию, отдельную команду убрать. Два входа в одно состояние расходятся при первой же правке правил. | |
| OQ1.1-11 | Код | Требование говорит: переход I завершает Приглашение дозаполнением профиля и подтверждением email. В коде полнота профиля считается по заполненности, а подтверждение email в нее не входит — намеренно, иначе действующие владельцы зон с неподтвержденной почтой разом уехали бы из S5 в S4. Из-за этого человек, дозаполнивший данные и не подтвердивший email, виден как S5, а кабинета еще не имеет. Достаточно ли фронту связки «состояние + признак подтверждения email» или нужен отдельный признак «приглашение завершено»? | Бизнес | Open | Достаточно связки: признак подтверждения email отдается в том же ответе, что и состояние. Отдельный признак заводить только если появится второе условие завершения приглашения. | |
| OQ1.1-12 | Код | Что подтверждено: приглашение на номер архивного Аккаунта отклоняется (BR1.1-15), человеку предлагается восстановиться самому. В коде владельцу зоны при этом не видно, что это за номер и почему нельзя — иначе отказ раскрывал бы факт существования чужой архивной учетной записи. Нужен ли владельцу более внятный сценарий — например, «пригласить после восстановления»? | Бизнес | Open | Оставить как есть до появления жалоб: любой более внятный текст раскрывает наличие Аккаунта на чужом номере. | |
| OQ1.1-13 | Код | Требование говорит: состояние Аккаунта складывается из трёх признаков и только из них — существование, полнота профиля, связь с партнёрской зоной (BR1.1-3, раздел 4). В коде с 05.09.26 резолвер состояния учитывает четвёртый признак — принято ли приглашение (HasPendingInvitationOnly): пока ни одна запись сотрудника не принята, аккаунт остаётся в S4 даже при полном профиле, даже если раньше был бы S5. Признак заведён после того, как этот раздел BRD в последний раз обновлялся (04.09.26) под приглашение по SMS — код успел уйти дальше формулировки «три признака и только из них».Решение уже принято и подробно объяснено в каноне docs/access-control/account-state-machine.md (раздел «Непринятое приглашение держит в S4») — вопрос не по существу правила, а по синхронизации текста BRD с ним.Нужно ли внести четвёртый признак в раздел 4 и комментарий BR1.1-3? Authentication.Domain/Accounts/StateMachine/AccountStateFacts.cs:20-27; AccountStateMachine.cs:33-44; используется в Authentication.Application/Accounts/Dtos/PartnerAccountDtoFactory.cs:163-173 | Разработка | Open | Обновить раздел 4 и комментарий BR1.1-3 текстом из канона (docs/access-control/account-state-machine.md): добавить признак «принято ли приглашение». Бизнес-решение уже принято и реализовано — правки чисто редакторские. | |
| OQ1.1-14 | Код | Требование говорит: аккаунт после удаления хранится 5 лет, после чего все данные из связанной карточки клиента удаляются (BR1.1-6). В коде хранение 5 лет реализовано: ArchiveCleanerJob раз в сутки запускает ArchiveCleanerUseCase.ExecuteAsync, который находит архивные аккаунты с ArchivedAt < UtcNow.AddYears(-5) и удаляет их из БД booking.authentication.Удаление данных связанной Карточки клиента при этом не найдено: DeleteAccountsAsync удаляет только строки accounts, события об удалении в booking.clients не публикуется (AccountDeletedEvent/аналог — не найдено за обход по обоим сервисам). Карточка клиента рискует остаться висеть без связанного аккаунта дольше 5 лет.Нужно ли публиковать событие об удалении в booking.clients, или удаление карточки не требуется?Authentication.Persistence/Repositories/Accounts/AccountRepository.cs:378-398 (GetArchivedAccountsAsync, DeleteAccountsAsync); Authentication.Persistence/Jobs/ArchiveCleanerJob.cs:24-37; Authentication.Domain/UseCases/ArchiveCleanerUseCase.cs:14-25 | Разработка | Open | Завести событие об удалении аккаунта из ArchiveCleanerUseCase/ArchiveCleanerJob, обработчик в booking.clients удаляет либо анонимизирует карточку. Либо явно зафиксировать в BRD, что автоматическое удаление карточки не входит в scope. |