в Fundamentals of Software Architecture, Книги

Что такое архитектура приложения? И кто такой архитектор?

У многих возникает вопрос: почему нигде не описан путь как стать архитектором приложений?

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

Архитектура это о самом важном, чтобы это не значило

Ральф Джонсон

Авторы книги, в итоге составили mind map:

Определение архитектуры не может быть четко сформулировано, так как экосистема разработки постоянно меняется. Если взять за основу определение из Википедии: “Архитектура приложения – это выбор основополагающих решений, которые очень дорого изменить после того как они были воплощены”. Однако если был выбран микросервисный архитектурный стиль, где за основу взят процесс постепенного расширения функциональности, то здесь структурные изменения уже не так затратны.

Большинство литературы по архитектуре уже устарело и больше представляет собой набор решений, которые были применены архитекторами, только чтобы осознать какой урон они нанесли.

Изучая архитектурные решения важно понимать, что они были отражением реалий того времени и окружения. Например, раньше всячески старались переиспользовать ресурсы, поэтому была одна огромная база данных, сервер приложений куда всё деплоилось, то есть всё упиралось в стоимость лицензий ОС, БД, сервера приложений. Поэтому было бы крайне затратно применять микросервисную архитектуру и закупать 50 лицензий ОС, БД и т. д.

Так что же такое архитектура?

Многие полагают, что “архитектура” – это шаблон (схема), либо конкретный набор задач (roadmap) для построения системы.

На самом деле архитектура представляет собой структуру системы вместе с архитектурными характеристиками, архитектурными решениями и принципами проектирования.

Из чего состоит архитектура системы

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

Архитектурные характеристики (architecture characteristics) – набор требований, никак не связанный с функциональностью системы, поэтому их также называют нефункциональные требования. Они не требуют знаний о системе, хотя необходимы чтобы система функционировала корректно. Например: расширяемость (scalability), гибкость (agility), производительность (performance), доступность (availability).

Архитектурные решения (architecture decisions) – набор ограничений (что можно, что нельзя) по которым должна быть построена система. Например, архитектор может принять архитектурное решение по которому только слои бизнес-логики (business layer) и сервисый (service layer) могут обращаться к БД, ограничивая слой представления (presentation layer) от прямых вызовов к БД. Если конкретное архитектурное решение не может быть применено к данной части системы, то допускается вариативность (отклонение от правила).

Принципы проектирования (design principles) – набор рекомендаций, а не жестких правил (ограничений). Например: рекомендуется использовать сообщения для обмена данными между микросервисами, в целях улучшения производительности, но при этом разработчик в праве выбрать (REST / gRPC), в зависимости от условий.

А архитектор?

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

Хорошо, определить роль архитектора мы не можем, но мы можем сформировать список ожиданий от архитектора. Следование этим ожидаением позволяет достигнуть эффективности и успеха.

Архитектор…

  1. Принимает ключевые решения – архитектор задает тренд, а не указывает конкретную технологию. Например, вместо того, чтобы выбрать конкретный фреймвор для фронтенда, например React.js, архитектор должен указать на использование реактивного фреймворка для фронтенда, а команда разработки сама выберет подходящее решение (Angular / Vue.js / React и т. д).
  2. Постоянно анализирует архитектуру
  3. Поддерживает архитектуру в соответствии с текущими трендами
  4. Проверяет соответствие принятым решениям
  5. Имеет опыт работы с разными технологиями или хотя бы знает их ± (см. T-shaped skills)
  6. Хорошо разбирается в предметной области
  7. Коммуникабелен
  8. Разбирается в текущих реалиях компании

Написать Комментарий

Комментарии