Как выделить доменную модель до создания экранов

Почему команды начинают не с того места

Команды часто начинают с экранов, потому что их легко показать. Форма регистрации, дашборд и несколько писем о статусе кажутся прогрессом. Но экраны показывают только поверхность.

Настоящая работа лежит глубже. Кто-то отправляет информацию. Кто-то её проверяет. Что‑то утверждается или отклоняется. Срок меняет дальнейшие действия. Если команда пропускает эту часть, она создаёт страницы, не договорившись о том, что система на самом деле делает.

Так правила оказываются разбросаны по продукту. Одно правило живёт в подписи выпадающего списка, другое — в письме-подтверждении, третье — в ночной задаче, а четвёртое — в инструкции службы поддержки. Через месяц никто не может объяснить полный процесс онбординга без открытия пяти инструментов и опроса трёх человек.

Небольшие расхождения в формулировках причиняют больше вреда, чем многие ожидают. Если на одном экране написано «активный», поддержка говорит «проверенный», а финансы — «утверждён», люди предполагают, что эти слова означают одно и то же. Часто это не так. Инженеры делают одно предположение, операторы — другое, а пользователи застревают посередине.

Простой пример иллюстрирует проблему. Основатель просит поток онбординга со шагами для настройки аккаунта, загрузки документов и проверки. Команда сразу проектирует три экрана. Позже выясняется, что некоторые пользователи могут пропускать проверку, кому‑то нужны дополнительные проверки, а некоторые документы истекают через 30 дней. Теперь нужно менять UI, фоновые задачи и сообщения, потому что команда моделировала страницы прежде, чем поведение.

Когда вы заранее называете бизнес‑объекты, действия и правила, разговор меняется. Дизайнеры, инженеры и поддержка начинают использовать одни и те же термины. Картирование рабочего процесса упрощается, потому что всем видно, где и почему состояние меняется.

Именно для этого обычно делается обзор архитектуры продукта: притормозить, прежде чем код распылит логику. Небольшая общая модель не усложняет работу. Она сокращает переделки, уменьшает время передачи задач и не даёт скрытым правилам просочиться в случайные экраны и джобы.

Начните с чеклиста онбординга

Начните с чеклиста, которым люди уже пользуются, а не с отшлифованной версии из презентации. Попросите того, кто выполняет работу, показать реальный документ, шаблон тикета, таблицу или чат. Если три команды проводят онбординг по‑разному, соберите все три варианта. Беспорядок полезен — он показывает, где реально живут правила.

Читайте каждую строку и помечайте, что происходит простыми словами. Одна строка может просить создать аккаунт. Другая — попросить менеджера утвердить запрос. Позже работа может передаваться в финансирование или IT. Это разные виды шагов, обозначьте их заранее. Обычно их можно разделить на четыре типа: действие, утверждение, передача или ворота, решающие, разрешён ли следующий шаг.

По ходу чтения обводите слова, которые называют вещи. В онбординге это может быть соискатель, сотрудник, контракт, ноутбук, запрос доступа или запись о обучении. Пока не приводите их в порядок. Если одна команда говорит «кандидат», а другая — «новый сотрудник», оставьте оба термина, пока не выясните, одинаково ли они используются.

Следите за местами, где люди останавливаются и спрашивают: «Можно ли это делать уже?» Обычно этот вопрос указывает на бизнес‑правило, даже если его не записали. Возможно, IT не выдаст учётные данные, пока HR не подтвердит дату начала. Возможно, расчёт оплаты не начнётся, пока не будет подписан контракт. Отмечайте такие места и продолжайте.

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

Если после этого чеклист всё ещё помещается на одной странице, это хороший знак. Инженеры, операторы и менеджеры могут прочитать его вместе и исправить до того, как кто‑то начнёт подключать экраны или фоновые задачи.

Шаг за шагом: превращаем шаги в команды

Шаг чеклиста часто скрывает реальное бизнес‑действие. «Проверить регистрацию», «приветственный экран» или «KYC‑страница» помогают говорить о потоке, но не говорят инженерам, что система должна делать. Перепишите каждый шаг как команду.

Хорошая команда — это простой глагол и объект. «Утвердить аккаунт» работает. «Утверждение аккаунта» слабее, а «экран утверждения» — просто название экрана. Команда должна звучать так, будто её может инициировать человек или система.

Затем добавьте актера. Кто‑то всегда начинает действие, даже если позже его запускает задача. Это может быть клиент, агент операций, менеджер или сама система. Запишите это — скрытые решения быстро вскрываются. «Система отправляет напоминание» и «агент поддержки отправляет напоминание» выглядят похоже, но задают разные правила.

Потом укажите, что должно уже быть верно. «Утвердить аккаунт» неполно, пока вы не скажете, что должно существовать: получили ли документы, подтверждён ли email или пройден ли риск‑ревью. Эти условия мешают командам строить интерфейсы и джобы на догадках.

Короткий перепис делает разницу понятной. «Проверить нового пользователя» становится «Операционный агент утверждает аккаунт». «Приветственная страница» становится «Система создаёт рабочее пространство». «KYC» становится «Агент комплаенса проверяет личность». «Письмо‑напоминание» становится «Система отправляет напоминание об онбординге». «Настройка оплаты» становится «Клиент добавляет способ оплаты».

Держите команды отдельно от названий экранов на всём протяжении. Экран может запускать несколько команд, а одна команда может встречаться в разных местах. Если назвать команду в честь экрана, интерфейс начнёт управлять моделью — именно так логика расползается по формам, джобам и админ‑панелям.

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

Найдите сущности и изменения состояний

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

Простой тест помогает: если продукт, поддержка и финансы будут использовать одно и то же существительное, оно, вероятно, должно быть в модели. Если существительное встречается только на одном экране или в одном отчёте, пока не включайте его.

Затем приведите названия в порядок. Команды часто говорят «пользователь», «участник», «клиент» и «аккаунт», как будто это разные вещи, когда на самом деле имеют в виду одно. Выберите одно название, напишите короткое определение и держите его постоянным. Если два слова действительно описывают разные бизнес‑объекты, разделите их сознательно.

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

Здесь проявляются реальные разногласия. Одна команда думает, что «утверждён» значит, что продажа проверена. Другая — что это юридическое согласование. Это не проблема названий, это проблема состояний.

Сопоставьте каждое изменение состояния с командой. Например: «Пригласить компанию» переводит компанию из draft в invited. «Утвердить компанию» переводит её из invited в approved. «Активировать аккаунт» переводит аккаунт из approved в active. «Приостановить аккаунт» переводит его из active в suspended.

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

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

Достаточно модели на простом языке: сущность, текущее состояние, разрешённые следующие состояния и команда, которая это состояние меняет. Когда это ясно, проектировать экраны и фоновые задачи становится намного проще.

Напишите инварианты до экранов и джобов

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

Именно поэтому инварианты стоит зафиксировать на бумаге до того, как кто‑то подключит экраны и джобы. Пропустите их, и каждый интерфейс придумывает свою логику. В админке можно сделать одно, в публичной форме — другое, а очередь джобов создаёт записи, которых никто не хотел разрешать.

Пишите каждый инвариант одной короткой фразой. Формулируйте просто и конкретно. «У заявителя может быть только одно активное дело по онбордингу». «Утверждение истекает через 30 дней». «Система отправляет приветствие только после прохождения верификации личности». Если предложение пытается сказать слишком много, разделите его.

Некоторые правила блокируют действие: «Не активировать аккаунт, пока не пройдёт оплата». Некоторые создают последующую работу: «Если документ истёк, создайте задачу на проверку». Некоторые делают и то, и другое: «Если через 30 дней нет обучения, блокировать доступ и открыть задачу по комплаенсу».

Это убирает догадки. Инженеры знают, отвергнуть систему, предупредить, поставить в очередь, повторить попытку или создать задачу для человека.

Держите временные рамки в самом правиле. Не пишите «истекает позже» или «через некоторое время». Укажите число. «Приглашение истекает через 7 дней». «Фончевая проверка истекает через 30 дней». Временные правила часто диктуют джобы, напоминания и аудиты, поэтому расплывчатые формулировки быстро приводят к переделкам.

Хорошие инварианты также указывают на изменения состояний ваших сущностей. Если команда говорит «утвердить заявителя», правило должно объяснять, когда утверждение разрешено, какой статус меняется и какая дополнительная работа запускается. Если двое людей читают правило и представляют разные результаты на 30‑й день, правило ещё нужно допилить.

Простой пример онбординга

Представьте нового сотрудника по имени Мая. Она отправляет фото паспорта и налоговую информацию до первого рабочего дня. Один такой шаг уже содержит три части: действие, запись и правило.

Действие простое: Мая отправляет документы. Записи — профиль сотрудника, загруженные файлы и текущий статус проверки. Правило тоже простое: HR не может продвинуть дело дальше, пока не будут все требуемые документы.

HR затем проверяет файлы. Если фото паспорта размытое или налоговый номер отсутствует, HR возвращает дело на доработку. Это отдельное действие, а не примечание в той же форме. Мая исправляет и снова отправляет документы, и дело возвращается на проверку.

После того как HR подтверждает документы, менеджер утверждает роль, команду и дату начала. Это разделение важно. HR подтверждает личность и налоговые данные. Менеджер подтверждает, где и когда Мая будет работать. Разделение действий упрощает понимание и последующий аудит.

Контракт тоже должен иметь своё место в модели. Подписанный контракт переводит запись сотрудника из «в ожидании» в «готов к расчёту зарплаты». Расчёт может начаться только когда выполнены оба условия: менеджер утвердил назначение, и Мая подписала контракт.

Теперь модель ясна в одном месте. Команды: отправить документы, запросить доработку, повторно отправить документы, утвердить назначение, подписать контракт и начать расчёт зарплаты. Сущности: сотрудник, набор документов, утверждение, контракт и профиль расчёта зарплаты. Инварианты: правила, которые всегда должны соблюдаться, например «нет расчёта зарплаты до утверждения» и «нет утверждения без роли, команды и даты начала».

Когда модель ясна, инженеры могут построить экран загрузки, очередь проверки HR и джоб расчёта зарплаты без догадок о том, как процесс должен работать.

Ошибки, которые приводят к переработке

Большинство переделок начинается до того, как написан хоть какой‑то код. Модель ещё расплывчата, поэтому команда заполняет пробелы экранами, cron‑задачами и дополнительными таблицами. Это кажется быстрым на неделю. Затем вылезают пограничные случаи, и люди начинают переименовывать поля, сливать записи и переписывать потоки, которые, как им казалось, уже завершены.

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

Ещё одна ловушка — называть команды в честь кнопок. «Нажать отправить» — не бизнес‑действие. «Отправить заявку» — это. Подписи кнопок меняются вместе с дизайном. Бизнес‑действие должно оставаться одинаковым на веб‑странице, в мобильном приложении или через API.

Команды также прячут правила в фоновых джобах, потому что такие джобы кажутся безопасным местом для очистки. Это вызывает путаницу позже. Никто не сможет просто ответить, когда аккаунт становится активен или почему один заявитель ушёл на ручную проверку. Джобы должны выполнять работу, а не решать политику.

Ещё меньшая ошибка даёт много мусора: смешивать одноразовые задачи с долгоживущими записями. «Отправить приветственное письмо» выполняется один раз. «Пользователь» остаётся годами. «Запросить недостающий документ» — событие или задача, а не основная сущность. При смешении такого рода отчёты становятся шумными, а старые элементы рабочего процесса остаются как будто всё ещё актуальны.

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

Быстрая проверка перед началом сборки помогает. Спросите для каждого пункта: это бизнес‑объект, бизнес‑действие или просто деталь экрана? Если ответ расплывчат, остановитесь и исправьте это прежде всего.