Функциональные требования: Domain Drive Design

90% успеха в разработке хороших продуктов лежит в хороших коммуникациях и правильных вопросах.

Сегодня поговорим про функциональные требования и DDD подход.

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

Когда мы говорим про бизнес-цели, важно выделить уже на этом этапе те цели, без которых данный продукт или задача не смогут работать (AS IS цели), и те цели, которые могут быть выполнены позже с горизонтом 5-7 месяцев (to be цели). Заказчик совершенно точно сможет сформулировать для вас все, что важно и что не важно на данном этапе.

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

Скрытые ограничения Наша самая главная задача в этом диалоге – не только сфокусироваться над целями AS IS, но и подумать над тем, какие есть ограничения. Например, требования извне, такие как требования регуляторов. Также ограничения могут быть физические, например, слабый канал или маленькие комнаты для серверов. Ограничения также могут быть финансовые, например, по количеству человек, которые могут работать на этом проекте. Все это может повлиять на объем необходимых работ.

Есть стандарт ISO 25010, который включает в себя множество пунктов атрибутов качества системы или цифрового продукта:

1⃣ Функциональная пригодность 2⃣ Уровень производительности 3⃣ Совместимость 4⃣ Удобство использования 5⃣ Надежность 6⃣ Защищенность 7⃣ Сопровождаемость 8⃣ Переносимость.

Рекомендую вам его использовать при диалоге с заказчиком и проработке требований.

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

Для примера давайте представим, что нам нужно реализовать 4 функции в MVP:

Процедурный подход 1⃣ Проверить наличие товара 2⃣ Добавить товар в корзину 3⃣ Оформить заказ 4⃣ Назначить время доставки

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

В этой парадигме все 4 функции как бы связаны логически, и все 4 модуля могут вызывать блокировки в БД и вызывать ожидания друг друга. Несмотря на 4 казалось бы простых функции, у нас с вами уже есть довольно непростые интеграции, и именно так рождается монолит.

Загвоздка в том, что логически кажется все правильно. С ростом требований и функций через процедурный подход мы сами создаем так называемые монолиты.

Мой канал - https://t.me/carbonka

(Продолжение в следующем посте)