```json
{
    "title": "Функциональная архитектура цифровых продуктов, часть 1",
    "url": "https://sherer.pro/blog/funkcionalnaja-arhitektura-cifrovyh-produktov-chast-1/",
    "datePublished": "2020-09-07",
    "dateModified": "2026-07-27",
    "language": "ru-RU",
    "description": "Что такое функциональная архитектура, зачем она нужна и почему рынок привык работать плохо.",
    "author": "Павел Шерер",
    "publisher": "Павел Шерер"
}
```

# Функциональная архитектура цифровых продуктов, часть 1

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

Этот пост (как и весь цикл) написан не только и не столько для инженеров и программистов, сколько для тех, кто проектирует цифровые продукты. Ну и для тех, разумеется, кто платит за это проектирование и последующую разработку.

## Определение функциональной архитектуры

Так что же такое Functional Architecture? Если коротко, то:

> **Функциональная архитектура** — это детальное описание и структура функциональности создаваемой системы, спроектированные с учётом технологических, пользовательских и бизнес-требований, а также иерархии функций, их зависимости друг от друга и использования в компонентах такой системы.

Слишком размыто? Как и всегда, когда кто-то пытается засунуть объёмную методологию в одно короткое определение. Давайте разбираться.

Представьте, что каждое событие в системе, самостоятельное или произведённое в ответ на действие пользователя, является *функцией*. Функции могут быть *общими*, *родительскими *и *дочерними*. Они могут объединяться в глобальные *функциональные разделы*, *зависеть *друг друга и *блокировать *другие функции.

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

## Перенос рисков

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

Мы привыкли, что разработка - это область проектного процесса с довольно высокой степенью неопределённости. Именно поэтому все агентства и production-компании работают по T&M, с оплатой по часам, а не по результату. Им просто невыгодно брать на себя финансовые риски клиента. Ведь на старте они не могут быть уверены в том, что информации достаточно, а документация по проекту верная и исчерпывающая. Зачастую разработчикам вообще прилетают только функциональные *требования*, юзкейсы и дизайн-макеты (разумеется, этого мало).

И что происходит в итоге? Правильно, риски перекладываются на клиента. Сорян.

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

Программисты вынуждены принимать решения и искать ответы на те вопросы, которые их вообще не должны касаться. Классика: *"а что будет, если соцсеть не вернула e-mail пользователя?"*. Или: *"а пользователю нужно сообщать о вот этой вот ошибке?"*.

Инженеры и строители начинают работать за архитекторов, если тем не хватает квалификации. Такое, блин, возможно только в IT.

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

## Деградация кода

Редко, очень редко на проекте есть выделенный архитектор. Такой, который загрузит себе в голову весь проект, выделит общие части, разложит всё по полочкам. А даже если он есть, он наверняка занимается общей (а не функциональной или программной) архитектурой проекта.

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

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

А представьте, что над проектом работает два, пять разработчиков? Какова вероятность, что они синхронизируются в мелочах вроде пагинации, "бесконечного" скролла или валидации данных? Что каждый из них не напишет в своей части проекта собственный вариант каждого решения?

А ведь это так просто: выявить все *общие функции* ещё на этапе проектирования и явно указать на них программистам. Не надеяться на авось, и не отмазываться зоной ответственности. Никто, кроме проектировщика/аналитика/дизайнера, не знает проект настолько хорошо, чтобы это сделать. Разумеется, если нет специального человека.

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

## Функциональные требования и описание

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

Это всё равно что написать "мост должен выдержать десять грузовиков, гружённых щебнем" и отдать это в виде задания строителям. Вряд ли последние смогут сваять что-то путёвое по такой "инструкции".

И даже если углубиться в это конкретное требование, расписать его максимально подробно (посчитав и вес одного авто, и удельный вес, и даже среднюю скорость проезда), то всё равно получится фигня. И не важно, десять таких "требований" будет или пять сотен. Строителям, как и разработчикам, нужны куда более полные и комплексные инструкции. Структурированные с учётом множества факторов. В противном случае строители просто залью всё армированным бетоном, чтобы уж наверняка.

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

И в следующих статьях мы поговорим об этом.

## Немного лирики

Многие идеи, изложенные мной в этой и следующих статьях цикла, родились в процессе общения с моим партнёром, Вадимом Митякиным. Кстати, он пишет [книгу](https://mityakin.com/redbook) - и если вы дочитали эту статью до конца, то книга вам наверняка покажется интересной.