Как вы уже могли заметить, мои предыдущие рассуждения о программной архитектуре так или иначе касаются проектирования, но четкого определения о том, что такое архитектура я до сих пор не привел. Что же, здесь я это сделаю, но прежде замечу, что определений много и единого мнения на этот счет нет. Мне встречались самые разные толкования. Начиная от ироничных:
Architecture is the stuff you can’t Google*, Neal Ford & Mark Richards.
*Архитектура – это то, что вы не сможете найти в Гугле (в моем вольном переводе).
И заканчивая серьёзными отраслевыми стандартами:
Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution*, [IEEE 1471].
*Архитектура – это фундаментальная организация системы, воплощенная в ее компонентах, их отношениях друг с другом и с окружающей средой, а также принципах, лежащих в основе ее проектирования и развития.
Лично для себя я сформулировал такую мысль:
Архитектура – это совокупность проектных решений, играющих важную роль в развитии программного проекта.
Эти проектные решения начинаются до того, как мы начинаем писать код и продолжаются в процессе его написания. Часто можно встретить упоминание о структуре программного проекта, которая выражает его архитектуру. В принципе – да, это верно, только структура (совокупность сервисов, классов, их взаимосвязи) – это далеко не единственный результат работы архитектора.
Также часто встречается упоминание о том, что архитектура – это что-то высокоуровневое, крупномасштабное. В принципе – тоже да, и это верно, только сводить всю архитектуру к крупномасштабным вещам неправильно. Архитектура – это не только глобальные решения, например, декомпозиция большой системы на микросервисы, но и «мелкие» решения тоже. Выделение классов, структур, определение их ответственности, даже нейминг (правильный выбор именований) и тот может затрагивать архитектуру. Все, что имеет существенное влияние на разработку, относится к архитектуре. За исключением разве что организационных моментов, но даже по этому вопросу есть разные мнения, вспомним про закон Конвея.
Архитектура имеет много параллелей со стратегией, так же, как и стратегия она вроде бы о чем-то глобальном, но есть ведь еще и тактика, которая неразрывна связана со стратегией. Образно говоря: «два сапога пара» и имея только один – далеко не уйдешь.
Забывая о тактике, о конкретных приземленных решениях на уровне кода, мы сводим архитектуру к величественному парению в высоте. Вроде и красиво, но бессмысленно, любые высоуровневые решения можно легко и непринужденно обесценить на тактическом уровне – в процессе разработки конкретных сервисов, классов, функций и т.д.
Поэтому говоря о архитектуре, стоит выделить макро и микроуровень (стратегию и тактику). Это условные термины и где проходит грань между макро и микро, не всегда понятно. Но в целом это про большую декомпозицию – на уровне сервисов и про малую – на уровне классов, структур, функций. Конечно, есть много других вопросов, например, выбор языка программирования, выбор фреймворка. Это к чему относится? Язык я бы отнес к макроуровню, а фреймворк где-то посередине. Есть вопросы инфраструктуры: сборка и развертывание исполняемого кода, выбор брокера сообщений, выбор базы данных. Это к чему? Наверное, это все-таки ближе к стратегии. Впрочем, можно сделать трехуровневую классификацию: стратегический, тактический, оперативный уровень и раскидать требуемые решения по ним.
На самом деле это не так важно: что к какому уровню относится, главное понимать, что масштаб решений может быть разным. При этом не стоит пренебрегать «мелкими делами», им тоже нужно уделять внимание. Каждое из такие мелких решений в отдельности, может быть, и не приведет к проблеме, т.е. если я ошибусь с выбором названия для класса или делегирую ему слишком много обязанностей, то это, конечно, не будет проблемой. Но совокупность таких решений рано или поздно проблемы создаст.
Поэтому говоря о проектных решениях, я подразумеваю не только большие решения из серии «пишем монолит или микросервисы?», но и решения на уровне классов, методов: «какой-то он слишком большой, лучше растащу его на несколько мелких» или «а здесь лучше использовать внедрение зависимостей».
На этом я пока закончу, продолжение следует.
Валерий Чугреев, 02.03.2021
А в моем понимании архитектура это именно «идея», умение выстраивать конструкции у себя в голове. Может сесть тысячу человек, искать компененты для будущего «фундамента» в Гугле. И у всех будет разная сборка! И даже при условии нахождении готовой идеи (плана) в Гугле, все равно надо будет как-то что-то перелопачивать под себя, свое понимание и видение. И возможно из тысячи собрать адекватно требованиям заказчика смогут всего десять человек, при условии что гугл для всех одинакого открыт.
А из этих десяти только тот один у которого есть понимание и опыт перспективы, сможет эту «идею» поддерживать на длительной дистанции в условиях постоянных изменений. Крайне ответственное дело. Я бы сгорел 🙂 наверное выкачиает большое количество сил, если человек прям не «дышит» пониманием и желанием как все сделать круто и правильно.