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