Архитектура ПО неизменно усложняется с годами – параллельно с появлением новых технологических решений и их внедрением в продукт. Это усложнение вполне закономерно: при создании каждого нового «что» встаёт вопрос «как?». Любая технология не существует в вакууме – она неизбежно имплементируется в уже существующую или только проектируемую систему, что рождает потребность в новых архитектурных решениях или адаптации старых. И если на вопрос «что» отвечают фреймворки, инструменты и готовые решения – как коммерческие, так и open-source, то на вопрос «как» отвечают паттерны, принципы, подходы и стили. В общем, всё то, у чего обычно нет бренда или авторских прав, в отличие от конкретных технологий от Microsoft или Nvidia. В какой-то степени усложнение архитектуры – это естественный процесс, который укладывается в готовые концепции System Design и наборы лучших практик в виде cookbook, описанных опытными архитекторами.

Но есть ли у процесса усложнения конечная точка, или он будет продолжаться бесконечно? И я не про гипотетический момент из будущего, когда настанет технологическая сингулярность, а про вполне реалистичные временные отрезки. Здесь будет вполне закономерно сослаться на моё предыдущее утверждение: пока появляются новые инструменты и решения, архитектура будет обрастать всё новыми принципами и паттернами. Но тут на сцену выходит третий вопрос – «зачем?». И отвечать на него правильнее уже с позиции бизнеса и коммерции. Когда мы создаём ПО, у нас есть определённые ожидания: закрыть потребность какой-то аудитории, решить актуальную проблему или, в конце концов, заработать денег. Для измерения успеха в достижении этих целей существуют конкретные метрики, позволяющие оценить и предугадать целесообразность тех или иных решений, а также дать объективную оценку полученному результату. В случае архитектуры чаще всего это метрики скорости производства, качества, затрат на реализацию и поддержку. Проще говоря, выбор использовать микросервисную архитектуру, EDA или всё вместе исходит из одной цели – за меньшее время и с меньшими затратами получить лучшее качество. А значит, если кто-то придумывает новый паттерн, применение которого позволяет сократить время доставки фичи на прод и при этом не выстрелить себе из будущего в ногу, – это хороший паттерн, и мы будем его использовать.

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

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