«Три уровня моделирования: почему архитектура ломается даже при правильных приоритетах»

В прошлых постах мы разобрали, что приоритеты не спасают, если нет модели. Теперь — ключевой вопрос: как именно моделировать, чтобы не пропустить ни одного уровня?

Представьте, что вы строите дом. Вы не начнёте с крыши. Сначала — фундамент, потом стены, потом крыша. С программными системами — то же самое. Три уровня моделирования — это три этажа, и прыгать между ними нельзя.

«Представьте три уровня моделирования:

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

Здесь мы отвечаем на вопрос: «Как именно работает бизнес, какие шаги, кто за что отвечает?»

Главная мысль: всё это — уровень заказчика. Здесь вы проверяете бизнес-логику до того, как перешли к коду.

Здесь мы отвечаем на вопрос: «Из каких объектов состоит система, как они общаются и как меняются состояния?»

Главная мысль: здесь вы проверяете, как система устроена внутри, прежде чем писать классы и методы.

На данном этапе преобладает язык UML (Unified Modeling Language), а также смежные инструменты, такие как DFD и STD, которые помогают детализировать потоки данных и состояния объектов.

UML (Unified Modeling Language) — это стандартный язык визуального моделирования для разработки ПО. Он не язык программирования, а «чертёж» системы, помогающий проектировать архитектуру, описывать логику и документировать код до его написания.

UML — это язык для архитекторов и разработчиков. Он отвечает на вопросы:

Здесь мы отвечаем на вопрос: «Как именно хранить данные и как принимать решения?»

Главная мысль: здесь вы проверяете, не сломается ли логика и база данных на этапе реализации.

На этом уровне мы спускаемся к деталям, которые увидят разработчики и администраторы баз данных. Здесь два ключевых направления:

1. Проектирование базы данных (ERD)

Диаграммы «сущность-связь» показывают, какие таблицы будут в базе данных, какие у них поля и как они связаны между собой. На этом этапе вы находите ошибки, которые на первых двух уровнях были не видны: потерянные внешние ключи, неправильные связи (один-ко-многим вместо многие-ко-многим), дублирование данных. Ошибка здесь — и система тормозит или теряет данные.

2. Формализация сложной логики (Таблицы и деревья решений)

Если в процессе есть сложные условия («если сумма больше N и клиент новый, то...», «если товар заканчивается, а поставка через 3 дня, то...»), их нельзя просто нарисовать стрелочками. Таблицы и деревья решений позволяют проверить все комбинации условий и убедиться, что ни один сценарий не пропущен. Ошибка здесь — и в продакшене система принимает неверное решение.

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

DFD использовался и для существительных (внешние сущности, хранилища), и для глаголов (процессы).

DFD — это мостик:

Поэтому DFD часто используют первым инструментом, чтобы «связать» бизнес-требования с системой. А потом уже рисуют UML (классы, последовательности) и ERD.

Выше мы говорили о моделировании как о способе «не пропустить ошибку». Но для бизнеса это ещё и способ сэкономить.

Три уровня — три риска. Если вы не моделируете, вы не управляете этими рисками. Вы просто надеетесь, что «пронесёт».

Именно поэтому я в своей работе всегда начинаю с аудита и моделирования. Это не «лишняя бюрократия». Это дешёвый способ найти ошибки до того, как они стали дорогими.

«Пример из практики: обработка отзывов на WB/Ozon»

Представьте, что мы хотим внедрить AI-агента для автоматической обработки отзывов. Как это выглядит через три уровня?

Мы рисуем процесс: отзыв поступает → его нужно классифицировать (позитив/негатив) → если негатив — передать менеджеру для ответа → если позитив — передать продуктологу для аналитики → ответ отправлен клиенту → процесс закрыт.

Ошибка, которую мы находим на этом уровне: в текущем процессе никто не собирает статистику по жалобам. Мы автоматизируем обработку, но не получаем аналитику. А значит, не видим, что клиенты жалуются на упаковку — и продукт не улучшается.

Мы проектируем классы: Отзыв, Клиент, Продукт, Ответ. Рисуем диаграмму состояний отзыва: «Поступил → Классифицирован → Требует ответа → Ответ отправлен → Закрыт». Рисуем диаграмму последовательности: как AI-агент обращается к API маркетплейса, как передаёт данные в CRM.

Ошибка, которую мы находим на этом уровне: диаграмма состояний показывает, что отзыв не может перейти из «Требует ответа» в «Закрыт», если не заполнено поле «Категория жалобы». А в ТЗ это поле не было предусмотрено. Добавляем — иначе система зависнет.

Мы проектируем таблицы: отзывы, клиенты, продукты, ответы, категории жалоб. Прописываем связи: один клиент — много отзывов. Один отзыв — одна категория жалобы.

Ошибка, которую мы находим на этом уровне: в таблице отзывов нет поля «Дата ответа», а значит, мы не сможем измерить скорость реакции. Добавляем — и потом считаем KPI «время от отзыва до ответа».

Итог: мы нашли и исправили три ошибки на этапе моделирования. Каждая из них стоила бы нам:

А на этапе моделирования это стоило перерисовать несколько стрелочек и добавить пару полей в таблицу.