проектирования
Архитектор конкретного приложения или как его ещё называют Application архитектор разрабатывает архитектуру конкретного приложения и отвечает за техническую реализацию. Именно он опускается на самый низкий уровень – уровень реализации, определяя на каких технология из доступных и как будет реализовано приложение, чтобы оно выполнено возложены на него задачи. Он работает в связке с командой для объяснения, каким образом его задумка должна быть реализована и почему именно так. Он не ограничивается разработчиками, а работает со всей командой, продумывая как программный код будет стыковаться с экосистемой, например, с базой данных. Так, решение, поместить логику с код приложения или в базу данных определяет он, и ему возможно потребуется создать прототипы для принятия правального решения. Для внедрения незнакомых технологий в команду, обычно, он изучает и экспериментирует с набором сходных технологий, создаёт тестовый стенд и демонстрируя команде, продвигает применение её.
Важно отметить, что архитектор полностью отвечает за техническую успешность проекта и только он определяет как проект должен быть реализован. Архитектор может не знать всех технологий, которые он запланировал к реализации, и может привлекать узкоспециализированных специалистов, но ответственность за правильный выбор остаётся на нём. Например, он, если для хранения логов была взята БД MySQL, потому что нет специалистов знакомых с нужными, и она не выдерживает нагрузки, то в провале виноват архитектор. Если же архитектор сделал правильный выбор, но его некому реализовывать, то это задача подбора персонала, а не проблема архитектуры. Архитектор нужно учитывать текущую ситуацию с кадрами и технологическим стеком, если у не на это есть возможность. Если есть реальный риск, что архитектура не может быть вписана в текущие ограничения, то проект признаётся не выполнимым, так как менеджер проекта, когда он не может вписать проект в сроки, бюджиет и функционал. После того, как проект признан не выполнимым при данных ограничениях, руководство начинает принимать меры по корректировке ограничений, например, увеличивает бюджет для найма новых специалистов, или пересматривает весь проект заново, например, из добавления логов для отслеживания ошибок в существующей системе принимается решение купить готовое решение, которое подобных ограничений не имеет.
Основными инструментами является код и готовые решения. Программный код или связывает готовые решения, такие как БД, или реализует недостающий функционал. От сюда вытекает два технических направления развития – знание организации кода и знания готовых технологий. Для организации кода используются паттерны проектирования, реализация которых обсуждается с командой разработки для того, чтобы они могли их реализовать. Паттерны не являются готовыми решениями, а шаблонами для построения архитектуры. GoF – наиболее популярный сборник паттернов проектирования, являющийся базовым