Всё про ИТ-архитектуру: монолит и микросервисы, системное мышление — интервью с Филиппом Дельгядо

Архитектура в ИТ – это не «нарисовать диаграмму» и не «выбрать стек». Это работа со сложностью: там, где одной команде уже тесно, где требования конфликтуют, а решения нужно держать в голове годами.

В этом интервью я, Александр Шулепов (телеграм-канал Shulepov Code), поговорил с Филиппом Дельгядо – архитектором финтех-продуктов и создателем сайта lekton.io – о том, с чего начинается архитектура, почему «монолит vs микросервисы» не решается одной фразой и какие навыки действительно определяют уровень специалиста.

Путь в ИТ и первые архитектурные задачи

Александр: Филипп, расскажите, как вы пришли в ИТ и позже – в архитектуру?

Филипп: Интерес к ИТ появился ещё в школе, это были 90-е. Я пошёл на матобеспечение, закончил и довольно быстро столкнулся с ситуацией: через полгода первой работы начальник ушёл, и большой проект «остался на мне». Пришлось думать уже не только про код, а про то, как система будет развиваться в ближайшие годы – со мной или без меня. С этого момента архитектура стала частью работы. Дальше я менял роли и «шапочки»: много лет был разработчиком (примерно 95% разработки и 5% архитектуры/менеджмента), а сейчас в основном занимаюсь технической архитектурой – меньше менеджмента и меньше кодирования, больше архитектурных вопросов.

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

Высшее образование и «архитектурное мышление»

Александр: Есть ли, на ваш взгляд, польза от высшего образования для архитектора?

Филипп: Польза есть – в выстраивании процессов мышления. Архитектору важно уметь работать со сложными системами: видеть связи, «бегать по уровням абстракции», удерживать разные представления об одной системе. В вузе редко дают архитектуру как набор практик – нам почти ничего не рассказывали про сложные архитектурные концепции. Но сильная база (в моём случае – математика) много дала и тогда, и сейчас: некоторые вещи я до сих пор вспоминаю из матмеховских курсов, потому что они пригождаются в реальной жизни.

Александр: То есть это, по сути, тренировка мышления?

Филипп: Любая работа – работа мышления, просто мышления бывают разные. Архитектору чуть важнее уметь работать с большими абстракциями и перемещаться между уровнями.

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

Где учиться архитектуре: книги, опыт, конференции

Александр: Где вы черпали знания в 2000-е?

Филипп: Тогда – книги и опыт. Многие книги «про хороший код» на самом деле содержат архитектурные идеи: Макконнелл, потом паттерны «Банды четырёх», позже – корпоративные паттерны. Фаулер – уже ближе к осмыслению архитектуры через рефакторинг. Важно и то, что представление об архитектуре развивалось вместе с карьерой: появляются новые тексты – и ты дорастаешь до уровня ответственности, где эти тексты начинают «ложиться». Отдельный перелом – конференции. Первый Highload++ был в 2007-м: там можно обсуждать сложные вопросы с коллегами из разных стеков и бэкграундов. Это помогает отличать «как должно быть» от того, «как работает на практике».

Архитектура часто «спрятана» в книгах про качество кода и структуру разработки.

Конференции и общение с практиками помогают проверить книжные идеи реальностью.

Архитектор — профессия или роль

Александр: ИТ-архитектор – относительно новая профессия?

Филипп: Архитектор – скорее роль (и даже набор ролей). Должности архитекторов были и раньше: ещё в 90-е была позиция «главного архитектора». Это продолжение идеи роли в крупных проектах, где нужен человек, отвечающий за глобальную координацию технических усилий. Сейчас архитекторов стало больше, и нередко словом «архитектор» называют уровень, близкий к principal/staff engineer – просто потому что эти грейды у нас прижились хуже.

«Архитектор» – не только должность, а функция координации решений на уровне системы. В больших компаниях это часто соответствует уровню principal/staff.

Сложные проекты: чему они учат

Александр: Был ли проект, который запомнился как особенно сложный?

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

Александр: Есть проекты, которыми вы гордитесь?

Филипп: Я бы сказал – почти всеми, которые дошли до продакшена. Сейчас у меня технологически самый сложный проект – большой карточный процессинг, где я один из архитекторов: сложные сценарии, тяжёлая предметная область, высокие требования к производительности. Это очень интересно. Есть и проекты вроде первых версий Яндекс.Денег (ныне U-Money), в которых я активно участвовал – тоже есть чем гордиться. А стартапы, которые «не выдержали проверку реальностью», – там было много полезного, но гордиться сложнее.

Самый частый архитектурный стресс – несоответствие «хорошей постановки» реальным потребностям.

Продакшен – главный критерий «повода гордиться»: реальность всегда строгий экзаменатор.

Что нравится и не нравится в работе архитектора

Александр: Что вам нравится в профессии?

Филипп: Нравится высокий уровень личной ответственности и независимости. Мне важно выбирать и отвечать за решения, а не просто следовать чужим техническим решениям. При этом «ответственность в ИТ» часто не про «страшные последствия», а про внутреннюю профессиональную ответственность: сделать качественно, чтобы не было стыдно смотреть коллегам в глаза через год, два, пять. Архитектура даёт свободу и ощущение масштаба: вы отвечаете не за кусочек кода, а за большой кусок системы. И мне эстетически приятно системное мышление – смотреть на систему «сверху» и с разных точек зрения.

Александр: Это врождённое или прокачивается?

Филипп: Это обучение и опыт. Ничего врождённого: математика, практика работы со сложными системами – постепенно развивается.

Александр: А что не нравится?

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

Архитектура даёт свободу решений и масштаб ответственности. Цена – текучка, рутина и более сложный выбор следующего проекта.

Усидчивость, концентрация и почему рутина – не монотонность

Александр: Усидчивость важна? Или в вашей работе её не так много?

Филипп: Концентрация и умение сфокусироваться важны в любой работе. Бывают задачи, где без погружения в контекст вы просто не сможете «разрулить» ситуацию: сначала 2 часа входите в контекст, потом 3 часа думаете – и только после этого появляется решение. Иногда над задачей приходится думать несколько дней.

Александр: Я спрашивал, что вам не нравится в работе, и вы сказали про монотонность – это про усидчивость и концентрацию?

Филипп: Я бы уточнил: речь скорее не про монотонность, а про рутинность. Это разные вещи. Рутинность – это много задач, часто похожих по типу, которые не всегда удаётся делегировать, и их всё равно нужно кому-то решать. Монотонность – когда вы делаете одно и то же, условно «перекладываете цифры из одного столбца Excel в другой».

Александр: То есть «рутина» не обязательно монотонна?

Филипп: Да. Это скорее обыденность: когда именно нет «нетривиальных челленджей» в формате «я не знаю, как это решать, но надо решить, пойду читать статьи». Такие задачи встречаются, но реже, чем хотелось бы. Часто задач много, они неприятные, но при этом достаточно простые.

Концентрация нужна регулярно: архитектурные задачи требуют глубокого погружения.

Рутина ≠ монотонность: рутина – это поток похожих задач, а монотонность – однообразие одного действия.

Можно ли стать архитектором без программирования?

Александр: А можно ли стать архитектором без знаний программирования?

Филипп: Solution-архитектором (архитектор решений) – можно, enterprise-архитектором (корпоративный архитектор) – достаточно легко. Software-архитектором (архитектор программного обеспечения), на мой взгляд, нет, потому что нужно понимать, как ваши идеи будут выражаться в коде. Желательно понимать не только язык, но и конкретный стек, фреймворки, экосистему. Иногда «красивые решения на картинках» оказываются очень плохими с точки зрения реализации – просто потому что нет готовых решений в экосистеме, и приходится слишком много писать руками. Не всегда разработчики могут это донести, и архитектору нужно уметь это предвидеть. Чем неудобнее программисту, тем выше шанс ошибки, а ошибки исправлять дорого: стоимость решения растёт резко.

Для solution/enterprise-уровня код не всегда обязателен, для software-архитектора – практически обязателен.

Архитектору важно учитывать «стоимость реализации»: неудобная реализация повышает риск ошибок и цену изменений.

Почему книги часто лучше видео (и где у видео своё место)

Александр: Что лучше для обучения – книги или видео?

Филипп: Я за книги. Видео сложно «перечитывать». «Десять часов видео» часто превращаются в «книгу на час» – человек читает быстрее, чем слушает. В тексте проще излагать сложные мысли: можно вернуться назад, сослаться на «пять страниц назад», держать логику линейно. В разговоре вам приходится повторять то, что было «пять страниц назад», потому что никто не запомнил. Видео хорошо для моторных навыков – «смотрите, как набирают код». Но понимание требует времени и часто лучше достигается через текст. Идеально – сочетание: теория и практика, как в вузах (лекции и семинары). Книга плюс набор практикумов/курсов – отличный вариант, но обычно это дорого.

Текст выигрывает там, где нужна сложная мысль и возможность вернуться назад. Видео полезно для демонстрации практики, но не заменяет системного понимания.

Топ книг «для мышления архитектора»

Александр: Какие книги вы бы рекомендовали?

Филипп: Если говорить именно про мышление, а не про «учебники по технологии», я бы выделил:

• «Гарри Поттер и методы рационального мышления» (Юдковский) – про рациональный подход, вероятности и концепции мышления, при этом читается легко.

• Любая книга по ТРИЗ. Мне нравится детская «Месяц под звёздами фантазии» – сложные концепции переданы просто.

• «Загадка Прометея» (Лайош Мештерхази) – пример критического анализа текста: работа не только с тем, что сказано, но и с тем, что не сказано.

• Лотман, «Статьи по семиотике и типологии культуры» / «Семиосфера» – семиотика полезна разработчику и архитектору, а у Лотмана ещё и очень хороший язык.

• «Сунь-цзы» в переводе и с комментариями Конрада – интересны и идеи, и то, как один и тот же компактный текст по-разному осмысляется разными людьми и эпохами.

Сильные «архитектурные» книги не всегда про архитектуру: часто они про рациональность, анализ и язык.

Полезнее всего то, что тренирует мышление и критическую проверку идей.

Как выглядит день архитектора: вопросы, тексты, RFC и ADR

Александр: Как обычно проходит ваш рабочий день?

Филипп: Много «мелочёвки»: вопросы от разработчиков и архитекторов, разбор техдизайнов, обсуждение решений. У нас две вечные проблемы индустрии – инвалидация кэшей и наименование, и обе регулярно приходится решать. Когда появляется «окно» (часто уже вечером), я пишу постановки и документы: RFC/RFP – обычно текстом, страница на внутренней «вики». Иногда туда добавляются маленькие фрагменты кода (3–5 строк) и простые схемы. Если решение затрагивает архитектуру всей системы, фиксируем выбор в ADR (ArchИТecture Decision Record): почему выбрали именно так, какие причины. Потом из этого рождаются задачи, оценки, сроки, планирование. Плюс – презентации и совещания, куда без них.

Работа архитектора – это коммуникации, фиксация решений и «упаковка смысла» в текст.

RFC/ADR – способ сделать решения проверяемыми и воспроизводимыми.

Что такое архитектура в ИТ и с чего она начинается

Александр: Как вы определяете архитектуру?

Филипп: Мне близко определение, которое цитирует Фаулер: архитектура – это про сложные вещи. Особенно там, где система выходит за пределы ответственности одной команды: технологии, способы их использования, взаимодействия компонентов, нефункциональные требования, модель предметной области, разные её представления и связи между ними.

Александр: Архитектура начинается с текста, а не с диаграмм и не с кода?

Филипп: Да. Архитектура начинается с текста; диаграммы – иллюстрации. Но дальше архитектура должна быть выражена в коде: хороший код показывает свою архитектуру (screaming archИТecture). Если архитектура в тексте и в коде расходятся – это проблема: значит, вы не очень понимаете, что делаете. И ещё: архитектура – это не только «статика» (как устроено сейчас), но и «динамика» (как система будет меняться). Например, план перехода с Postgres на другую БД – это тоже архитектура. Динамику описывать сложнее: текстом можно, а универсальных диаграмм «про изменения» я не знаю.

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

Качество кода и качество системы

Александр: Архитектор следит за качеством кода?

Филипп: Архитектор следит за качеством системы. Есть архитекторы, которые активно делают code review, но я делаю это редко – только в критических местах. Важно понимать, кто должен проверить конкретный кусок: параллельность – к сильному сеньору, работа с БД – к профильному специалисту. Это скорее про выстраивание процесса обеспечения нужного качества: какие проверки нужны, кто отвечает, где риски.

Архитектор не обязан быть «ревьюером всего». Его задача – обеспечить качество системы через процессы, ответственность и правильную экспертизу.

Виды архитекторов и границы ответственности

Александр: Какие бывают архитекторы?

Филипп: Есть несколько распространённых специализаций:

• Software/System archИТect – ближе к системному дизайну компонента/продукта, много про реализацию и доменную область.

• Solution archИТect – собирает решение из подсистем/продуктов, часто на интеграциях (ERP, банковские «коробочки» и т. п.).

• Enterprise archИТect – больше про общую картину бизнеса и согласование архитектурных слоёв; техники меньше, «как должно выглядеть» – больше. Плюс отдельные специализации: инфраструктурные архитекторы, data-архитекторы и др.

В общем виде архитектор появляется там, где сложность не решается внутри одной команды. Чем больше компания, тем больше слоёв архитектуры: в условной компании на 50 человек часто хватит 1–2 software-архитекторов, на 300 – появляются solution-архитекторы, на 3000 – сложно жить без enterprise-архитектуры.

«Архитектор» – зонтичный термин: роли и компетенции сильно различаются.

Архитектура возникает на стыках команд, доменов, бизнеса и технологии.

Коммуникация и конфликтология: без этого архитектор не выживает

Александр: Бывают ли конфликты, несогласные с вами?

Филипп: Конечно. Софт-скиллы архитектору нужны не меньше хард-скиллов. Разработчик может «выжить» только на хард-скиллах, архитектор – нет. Нужно уметь договариваться и решать конфликты даже в темах, где вы не лучший эксперт. Иногда помогает простой разбор плюсов/минусов и выделение спорных пунктов. Иногда конфликт не решается – тогда приходится сказать: «Мы будем делать так» не потому что это идеально, а потому что иногда лучше любое решение, чем никакого.

Александр: Как избежать конфликтов?

Филипп: Никак. Конфликт – нормальное явление. Важно, чтобы профессиональный конфликт не переходил в личный. Архитектор «между» областями, поэтому шишки летят со всех сторон: разработчики, бизнес, продакты – у каждого свои критерии.

Конфликты неизбежны: вопрос не в том, «как избежать», а в том, «как работать».

Архитектору нужны навыки коммуникации, фиксации решений и отделения рабочего от личного.

Что такое «архитектурное мышление»

Александр: Какие качества важны для архитектора?

Филипп: Архитектурное мышление – для разных задач оно разное. Для меня ключевое – умение бегать между уровнями абстракции: от диаграмм и дискуссий к реализации и обратно. Вы смотрите на дизайн – и понимаете, какие сервисы появятся, как они будут работать с БД, какие индексы понадобятся, где дизайн плохой. Потом – «на три этажа вверх» обратно. Иногда доходите до того, как особенности кэшей на уровне процессора влияют на реализацию финансовых транзакций. Плюс – коммуникация и навыки чтения/письма: понимать, что написано, а не что хочется прочитать, и писать так, чтобы вас поняли корректно.

Архитектурное мышление – это «прыжки по абстракциям» и понимание последствий решений.

Чтение, письмо и коммуникация – базовые рабочие инструменты архитектора.

Деньги, рынок и дефицит архитекторов

Александр: Сколько могут зарабатывать ИТ-архитекторы?

Филипп: Как и программисты – «сколько угодно», в зависимости от уровня. Я видел вакансии 200–300 тысяч в месяц, и знаю архитекторов, которые получают больше миллиона. Это очень разные работы: разные уровни ответственности, hard/soft skills. Большие суммы часто у тех, кто совмещает архитектуру и управление большим контуром. На уровне 200–300 тысяч часто больше «про фиксацию решений», чем «про принятие решений».

Александр: Есть дефицит архитекторов?

Филипп: Вакансий много. Дефицит – в качестве архитектуры: людей с сильным бэкграундом, поставленным мышлением и пониманием «что и почему они делают» мало, как и высоких профессионалов в любой сфере. Но если смотреть на то, что архитектору работу искать обычно дольше, чем программисту, то «гигантского дефицита» нет. И если цель – только деньги, то часто выгоднее становиться сильным разработчиком. Архитектура – больше про влияние и возможность менять систему.

Вилка зарплат огромная: архитектура очень разная по роли и ответственности.

«Дефицит» чаще в уровне специалистов, а не в количестве людей с названием «архитектор».

Ошибки начинающих архитекторов и как учиться правильно

Александр: Какие ошибки вы видите у начинающих архитекторов?

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

Александр: Что бы вы посоветовали начинающим?

Филипп: Читать книги с включённым внутренним критиком. Фаулер, Ричардсон и другие сильные авторы – умные люди, но у них была своя эпоха, свои ограничения и контекст. Спорьте с текстом: для каждого абзаца думайте, в каких случаях это не работает, какие контрпримеры возможны, какие граничные условия. Это тренирует тот же навык, который нужен при чтении постановок: понять, что продакт или заказчик на самом деле хотел, какие ограничения и последствия скрыты.

Главная ошибка – воспринимать книжную фразу как универсальную истину.

Лучший режим обучения – «спорить с автором» и искать границы применимости.

Архитектура как управление сложностью

Александр: Почему важно работать со сложностью?

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

Архитектура – это управление сложностью, а не её «устранение».

Документация и абстракции – способ расширить «память команды».

Системное мышление: не один термин, а традиции

Александр: Что вы вкладываете в «системное мышление»?

Филипп: Там много традиций: теория систем, системная инженерия, системный анализ – и они по-разному понимают одно и то же. Для меня важнее, чтобы выбранный набор привычек работал со сложными системами. Это как в единоборствах: традиций много, но в реальной ситуации вам нужна хотя бы одна, освоенная. С системным мышлением так же.

Александр: У вас одна традиция?

Филипп: Да, моя ближе к общей теории систем с элементами ТРИЗ: система как элементы и связи, вложенные иерархии, динамика, разные точки зрения. Я даже делал доклад про своё понимание теории систем для архитектора – там часть этих идей раскрыта.

«Системное мышление» – не единое определение, а набор школ и практик.

Важно не название школы, а умение применить её к реальной сложности.

Архитектура и бизнес: единый язык предметной области

Александр: Как архитектура связана с бизнесом и языком компании?

Филипп: Архитектура нужна для задач бизнеса, поэтому архитектор обязан понимать долгосрочные интересы и говорить на языке предметной области. Важно не делать решение на «10 тысяч TPS» для бизнеса, который никогда не будет так расти – и наоборот, если рост – смысл бизнеса, архитектура должна это учитывать. Масштабирование часто обсуждают потому, что это измеримо и просто. Но способность к модификации часто важнее – просто её сложно измерять, поэтому про неё меньше говорят, но думать нужно. Идеальный вариант – единый язык бизнеса и разработки (DDD): слова в коде должны совпадать со словами бизнеса там, где это важно.

Александр: Есть «лайфхак», как поймать язык?

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

Архитектор обязан понимать предметную область и долгосрочные интересы бизнеса.

DDD и ивентсторминг помогают выстроить общий язык и снизить стоимость коммуникации.

Аналитик и архитектор: где граница

Александр: Чем отличается аналитик от архитектора?

Филипп: «Аналитик» – очень расплывчатая роль, как и «архитектор». В среднем аналитик – про требования: выявление, непротиворечивость, превращение видения продакта в сценарии. Но в реальности аналитики часто делают многое: техрайтинг, проектирование API, даже структуру БД. На мой взгляд, это не всегда правильно, но это отдельная большая тема, которая часто вызывает холивары.

Роли «аналитик» и «архитектор» сильно зависят от компании и процессов. В здоровом варианте аналитик – про требования и сценарии, архитектор – про системные trade-off и качество на горизонте.

Монолит и микросервисы: почему «единого ответа» нет

Александр: Можете коротко объяснить, что такое микросервисы и монолит – и что выбирать?

Филипп: Термины размыты. Сейчас под микросервисами обычно понимают распределённую систему из сервисов, взаимодействующих через современные каналы связи (HTTP, Kafka/RabbИТMQ и т. п.) и живущих в современном процессе разработки. Монолит – предельный случай: один элемент деплоя, меньше распределённых взаимодействий, больше «внутри памяти», проще с транзакциями. Чем крупнее блоки – тем часто легче жить. Любая распределённость резко увеличивает требования к людям и к системе: corner-кейсы, недоступность, порядок сообщений, гарантии и т. д. Чем меньше сложного – тем лучше. При этом масштабируемые монолиты возможны, я такие делал.

Александр: То есть нельзя ответить «что лучше»?

Филипп: Нет единого ответа. Архитектура – это всегда trade-off. Есть несколько решений, и нужно выбрать наиболее подходящее в конкретных условиях и горизонте планирования. Иногда решение «не оптимально сейчас», но станет оптимальным позже – и это всегда риск, потому что будущее никто не знает.

Микросервисы и монолит – это не «хорошо/плохо», а выбор компромиссов.

Распределённость добавляет сложность; если можно жить проще – обычно стоит жить проще.

О проектировании границ микросервисов и контекстов

Александр: Как вы проектируете границы микросервисов и контекстов?

Филипп: Универсального решения нет. В DDD bounded contexts часто находят по лингвистическим конфликтам: когда одну сущность называют разными словами или одно слово означает разные вещи – это потенциальная граница. При этом границы сервисов и границы контекстов не обязаны совпадать «1 к 1»: может быть несколько контекстов в одном сервисе или один контекст, реализованный несколькими сервисами – важно, чтобы контексты не пересекались. Ещё один практичный критерий – нефункциональные требования: если в одном сервисе начинают конфликтовать безопасность, нагрузка, модифицируемость и т. д., сервис имеет смысл разделить.

Границы удобно искать через язык (DDD) и через конфликты NFR.

«1 сервис = 1 контекст» – не закон природы; важнее не пересекать контексты.

Как начинать разработку, чтобы не получить хаос

Александр: С чего начать, чтобы не было хаоса?

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

Стартуйте проще, но закладывайте рефакторинг как норму жизни.

Ошибки неизбежны без знания домена; архитектура – это ещё и про адаптацию.

Типовые ошибки при переходе на микросервисы

Александр: Какие ошибки чаще совершают компании при переходе на микросервисы?

Филипп: Частая ошибка – сам переход «ради перехода». Люди, которые не смогли сделать монолит, редко смогут сделать более сложную распределённую систему. Если проблема в time-to-market (время вывода на рынок), иногда лучше привести в порядок монолит: модульность, структурные границы. Иногда есть промежуточные варианты – когда монолит остаётся, но часть компонентов вынесена наружу из-за других нефункциональных требований или потому что их делает другая команда. Иногда же нет выхода: «никто не знает, как монолит устроен», приходится собирать требования заново и строить новую систему – но и тогда стоит каждый раз критически челленджить необходимость микросервисности.

«Микросервисы как лечение» без диагноза – рецепт дорогих проблем. Часто правильнее сначала научиться делать понятный монолит с границами.

Инструменты архитектора: Confluence, бумага, UML и ArchiMate

Александр: Какие инструменты вы используете?

Филипп: Главный инструмент – база знаний (у нас это Confluence): тексты, схемы, фиксация решений. И очень важный инструмент – лист бумаги с ручкой.

Александр: Что вы думаете об Archimate и UML?

Филипп: Это разные вещи. UML – это один из наиболее популярных графических языков, на котором рисуют диаграммы, которые что-то описывают. Я регулярно использую UML, прежде всего sequence-диаграммы. Это хороший иллюстративный материал: процесс можно описать так, чтобы разработчик (и не разработчик) понял, что происходит. Я использую подмножество UML и иногда рисую «свои квадратики и стрелочки», если нужных артефактов в UML нет. А ArchiMate – более тяжёлая, всеобъемлющая нотация. Я ею не владею и считаю, что она чаще нужна на уровнях очень больших организаций/проектов (когда масштабы – тысячи людей). До уровней 300–800 человек это не всегда оправдано. У Коуберна есть прекрасная статья «Каждому проекту своя методология», где он подробно описывает, что существуют разные оси, по которым можно измерять проекты, и для каждой клеточки в этой многогранной матрице нужны свои подходы. Это важно держать в голове каждый раз, когда вы выбираете инструменты. Возможно, ArchiMate нужен для небольших проектов, но сверхважных по качеству, или для предварительного проектирования, или, наоборот, для огромных проектов с меньшими требованиями. Важно понимать, для каких «кирпичиков» подходит ArchiMate или любой другой инструментарий. Это ещё и интересная внутренняя задача – почувствовать, выросли ли вы из прежних рамок, не «жмут» ли старые инструменты и нужны ли новые. Лично я пока не доходил до момента, когда мне был действительно нужен ArchiMate.

Александр: Вы используете визуальные модели в общении с командой?

Филипп: Да, много рисую: на доске, в документации. Потом это превращается во что-то UML-образное, C4-образное или просто «квадратики-стрелочки-пояснения».

В реальности архитектура живёт в «вики», заметках и простых схемах.

UML (особенно sequence) – рабочая лошадка; ArchiMate нужен далеко не всем и не всегда.

Нейросети в работе архитектора: польза есть, но проверка обязательна

Александр: Используете ли вы нейросети?

Филипп: Нам придётся это использовать. Для разработчиков инструментариев пока больше, чем для архитекторов, но сценарии уже понятны: например, RAG + поиск по Confluence, чтобы быстрее находить информацию в корпоративной базе знаний.
Я регулярно обсуждаю вопросы с ChatGPT не потому, что он даст хороший совет – по большей части советы бывают слабые, и значимую часть нужно отбрасывать. Но модель может подсветить забытый аспект, предложить источник или новую технологию. Дальше всё равно надо проверять и разбираться самому. Важно понимать: чтобы получить хороший ответ, нужно понимать большую часть вопроса. Если задавать общий вопрос вроде «что лучше – монолит или микросервисы», модель выдаст усреднённый ответ, который ещё и зависит от контекста.

Александр: А ИИ-агентов пробовали?

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

LLM полезны как «подсветка» и ускоритель поиска, но не как источник истины.

Качество ответа зависит от качества вопроса и ваших критериев проверки.

Где вы сейчас работаете и зачем выступать на конференциях

Александр: Чем вы сейчас занимаетесь: компания, консалтинг?

Филипп: Я один из архитекторов компании, которая делает карточные процессинги. Сложная предметная область, много архитекторов, и мы делим зоны ответственности, иногда «залезая» в чужие – потому что нужно срочно решать. Это живой динамический процесс.

Александр: Зачем вам выступления на конференциях?

Филипп: Цели разные. Один из подходов: если хотите разобраться в теме – научите кого-нибудь другого. Плюс это про корпоративный бренд и личный бренд: проще задавать вопросы, проще находить работу, когда вы можете что-то показать. И мне нравится сам процесс подготовки и выступлений.

Публичные выступления – способ глубже разобраться в теме и усилить профессиональную репутацию.

В архитектуре ценится способность «упаковывать сложное» и объяснять другим.

Личное: хобби, планы, мечта и саббатикал

Александр: Есть ли у вас хобби?

Филипп: Да, я много танцую: социальные танцы – заметная часть жизни и свободного времени.

Александр: Если убрать архитектуру, чем бы вы занимались?

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

Александр: У вас есть мечта?

Филипп: Скорее цели, чем мечты. Для меня мечта – это то, что «внезапно случится само», а цель – то, к чему вы идёте. Из ближайших целей – сделать канал и привести в порядок то, что я накопил за годы. Может быть, когда-нибудь написать книгу, но идея книги меняется быстрее, чем я успеваю сесть писать. А мечта – sabbatical: уйти на полгода, чтобы спокойно написать большой текст, и чтобы при этом продолжали платить зарплату. Это уже больше про мечту.

«Мечта vs цель»: цель – в зоне вашего контроля, мечта – скорее «вне власти».

Долгие форматы (канал, книга) упираются в самое дефицитное – время.

Глоссарий

Архитектура и устройство системы

• ИТ-архитектура – «как устроена система» на уровне крупных частей: из чего состоит, как части взаимодействуют и как система будет меняться со временем.

• Сложность (в системах) – когда систему уже нельзя «удержать в голове»: слишком много компонентов, связей, требований и нюансов.

• Компонент / модуль – крупный «кусок» системы, который выполняет понятную роль (например, модуль оплаты или модуль авторизации).

• Распределённая система – система, где части работают отдельно (часто на разных серверах) и общаются по сети.

• Монолит (монолитная система) – когда приложение разворачивается как один большой «элемент деплоя»: внутри всё теснее связано, а взаимодействий «по сети» меньше.

• Микросервисы – подход, где система состоит из нескольких сервисов, которые общаются между собой по сети (например, через HTTP или очереди сообщений).

• Сервис – отдельная часть системы (обычно отдельное приложение), отвечающая за конкретную область: например, «платежи» или «уведомления».

• Деплой (deployment) – «выкладка» новой версии приложения в рабочую среду (на сервер/в облако), чтобы пользователи начали ей пользоваться.

• Trade-off (компромисс) – выбор между плюсами и минусами: «идеального решения» нет, есть наиболее подходящее в вашем контексте.

• Corner-кейсы (угловые случаи) – редкие, неприятные ситуации «на границе»: сбой сети, задержка сообщений, недоступность сервиса и т. п.

• Транзакции – способ делать операции с базой данных «целиком или никак»: либо всё выполнилось, либо ничего не изменилось (чтобы не получить «полусохранённые» данные).

Требования, домен и «язык бизнеса»

• Предметная область (домен) – то, про что ваш продукт «в реальности»: банковские операции, бронирование отелей, доставка, страхование и т. д.

• Модель предметной области – описание ключевых понятий домена и связей между ними: какие сущности есть и как они взаимодействуют.

• DDD (Domain-Driven Design) – подход, где разработка строится вокруг домена и языка бизнеса: важно, чтобы слова в коде совпадали со словами бизнеса там, где это нужно.

• Bounded Context (ограниченный контекст) – «зона смыслов», где термины имеют однозначное значение. Если одно и то же слово в разных местах значит разное – это сигнал, что контексты нужно разделять.

• Лингвистический конфликт – когда люди называют одно и то же разными словами или одним словом называют разное: обычно это признак границы между контекстами/частями системы.

• Нефункциональные требования (NFR) – требования не про «что система делает», а про «как она это делает»: скорость, надёжность, безопасность, удобство изменений и т. п.

• Time-to-market – насколько быстро вы можете выпустить фичу/изменение «в рынок» (до пользователя).

• Ивентсторминг (Event Storming) – рабочая сессия с экспертами, где «достают» термины домена и согласуют границы смыслов.

Роли в архитектуре

• Software/System ArchИТect – архитектор ближе к реализации конкретного продукта/компонента: много про код, домен и реальные ограничения разработки.

• Solution ArchИТect – «собирает решение из частей»: интеграции подсистем и продуктов, часто на стыках.

• Enterprise ArchИТect – отвечает за «общую картину» на уровне компании: согласование подходов и слоёв архитектуры.

• Аналитик – роль, которая чаще про требования и сценарии; на практике границы с архитектором зависят от компании и процессов.

Документы, фиксация решений и «внешняя память команды»

• Вики / база знаний – место, где команда хранит договорённости, схемы и решения, чтобы «не держать всё в голове».

• Confluence – популярная корпоративная «вики-система» для базы знаний (статьи, схемы, решения, правила).

• RFC (Request for Comments) – документ-черновик для обсуждения идеи: что предлагается и почему, чтобы собрать комментарии до внедрения.

• ADR (ArchИТecture Decision Record) – короткая запись «мы выбрали вот это решение, потому что…», чтобы позже было понятно, откуда выбор взялся.

• Фиксация решений – привычка записывать важные договорённости, чтобы решения были проверяемыми и воспроизводимыми (а не «держались на памяти» отдельных людей).

• Рефакторинг – улучшение структуры кода без изменения внешнего поведения: «навести порядок», чтобы дальше было проще и безопаснее менять систему.

• Code review (ревью кода) – когда другой разработчик смотрит изменения, чтобы поймать ошибки и улучшить качество; архитектор делает это не всегда, чаще – точечно в критичных местах.

Диаграммы и нотации

• UML – набор «условных обозначений» для схем: помогает быстро объяснить, как устроена система или как идут взаимодействия.

• Sequence-диаграмма (UML Sequence) – схема «кто кому что говорит и в каком порядке» (сообщения между частями системы).

• C4-модель (C4-образное) – способ рисовать архитектуру «крупно → детально»: от системы целиком к контейнерам/компонентам.

• ArchiMate – более «тяжёлая» нотация для очень больших уровней (организация/портфель/ландшафт систем); нужна далеко не всем.

• «Квадратики-стрелочки» – простые схемы «блоки и связи», которые часто лучше всего работают в реальном обсуждении.

• Screaming ArchИТecture («кричащая архитектура») – идея, что структура кода должна «говорить», что это за система: по кодовой базе видно домен и устройство, а не только технические детали.

Технологии и коммуникации между сервисами

• HTTP – «язык общения» в интернете: по нему сервисы могут запрашивать данные друг у друга.

• Очереди сообщений – способ обмениваться сообщениями «не напрямую»: один сервис кладёт сообщение, другой забирает, когда может.

• Kafka / RabbИТMQ – популярные системы очередей/стриминга сообщений для обмена событиями между сервисами.

• Postgres (PostgreSQL) – популярная база данных; даже «план миграции» с одной БД на другую – это тоже часть архитектуры.

Нейросети и работа с корпоративными знаниями

• Нейросети / LLM (Large Language Model) – модели, которые умеют понимать и генерировать текст; полезны как помощник, но ответы нужно проверять.

• ChatGPT – пример LLM-сервиса; может подсказать идеи или напомнить аспекты, но не заменяет проверку и понимание контекста.

• RAG (Retrieval-Augmented Generation) – подход «модель + поиск»: сначала ищем информацию в вашей базе знаний (например, в Confluence), затем модель формирует ответ на основе найденного.