Что такое архитектура ПО?

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

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

Аналогично и с архитектурой приложения. Иногда мы создаем систему с нуля и проектируем , как будет устроено наше приложение. Но чаще мы работаем уже с существующей системой, где уже есть какие-то компоненты, взаимосвязи и ограничения. И чтобы в ней что-то изменить или доделать, нам надо знать как она устроена. А бывает, что никто про архитектуру и не думал, все как-то исторически сложалось, но если есть приложение, то у него всегда есть какая-то архитектура. И мы можем выяснить как же все работает на самом деле и зафиксировать это.

Можно ли делать что-то без продумывания архитектуры?

Можно! Но чем сложнее система, чем больше разных компонентов и взаимодействий она включает, чем больше к ней разнообразных требований от разных групп заинтересованных лиц, тем сложнее. Забор можно поставить и без плана, а вот с ремонтом квартиры будет уже сложнее. Не говоря уж о строительстве дома.

В книге Head First Software Architecture авторы предлагают рассматривать архитектуру ПО, как паззл из четырех деталей:

⏺️Архитектурные характеристики
⏺️Архитектурные решения
⏺️Логические компоненты
⏺️Архитектурный стиль

В следующих постах расскажу про них поподробнее.
Часть 1/4 ⏬

#книги
#ZenTest

Часть 2/4. Начало ⏩

Архитектурные характеристики

Выбрать дом с садом в маленьком городе или квартиру в мегаполисе? Для разных людей важны разные параметры!

Так в программной архитектуре надо определить важные характеристики именно для этой системы.Должна ли система выдерживать большую нагрузку? Или соответствовать определенным критериям безопасности? А может обеспечивать высокую доступность?

Чаще всего эти характеристики называют нефункциональными требованиями. Но авторы книги предпочитают термин архитектурные характеристики, чтобы подчеркнуть, что они не менее важны, чем функциональные требования. Архитектурные характеристики задают как система должна что-то делать и какими качествами обладать.

Их очень важно продумать заранее насколько мы можем, потому что чаще всего их не получится развивать итерационно, мы оказываемся скованы уже существующими ограничениями решений. Мы можем обнаружить, что, чтобы поддерживать например высокую производительность нам надо много всего переделывать. Знаю пример, когда всю систему пришлось переписывать со Scala на Java, хотя технически Scala подходила лучше. Причина? Компания быстро росла и не могла нанимать столько Scala-разработчиков сколько ей было нужно, слишком мало специалистов было на рынке.

А еще архитектурные характеристики нередко противоречат друг другу и нельзя получить сразу все. Например сделать очень безопасную систему с шифрованием на каждый чих и при этом сделать ее же очень высокопроизводительной.

Кроме того бывают явные характеристики (эксплицитные), которые следую из бизнес-потребностей, а бывают неявные (имплицитные), которые кажется сами собой разумеются, но на самом деле конечно нет. Задача архитектора выяснить все это и договориться об ограниченном наборе того, на чем будем фокусироваться.

Архитектурные решения

Часто, когда речь идет о документации, люди записывают в лучшем случае, что решили, но не почему. А это часто самое важное! Сами решения можно восстановить в ходе археологических раскопок в коде, а вот почему так сделали остается только в памяти у людей.

В архитектуре есть два основных закона, которые мы берем за аксиому.

1⃣ Все в программной архитектуре — баланс «за» и «против». Нет никакой серебряной пули или идеального решения, которое не имело бы недостатков. А если вы их не видите, то вы недостаточно глубоко разобрались в теме.

2⃣ Почему важнее, чем как

Ок, мы поняли, что важно фиксировать архитектурные решения. Как же это делать? ADR (Architecture Decision Record)!

Есть различные шаблоны, но в минимальном варианте в ADR фиксируется контекст, само решение и почему оно было принято, последствия этого решения для системы. Кстати, это полезно не только архитекторам, а всем ролям)

#книги
#ZenTest

Часть 3/4. Предыдущие части ⏩

Логические компоненты

Логические компоненты — это строительные блоки системы, как например разные типы помещений в доме. Вот есть кухня, а вот ванная комната, а здесь будет гостиная. Так и логические компоненты отвечают за определенную функциональность, например за создание заказа или обработку платежа.

Логические компоненты непосредственно связаны с иерархией папок в коде и по ней можно выяснить, какие они есть. Как в примере из книжки.

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

Для того, чтобы выделить основные логические компоненты программисты анализируют бизнес-требования.

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

#ZenTest
#книги

Часть 4/4. Предыдущие части  ⏩

Архитектурный стиль

Обычно когда мы говорим об архитектуре, то обычно говорим именно об архитектурном стиле. Например обсуждаем микросервисы. Но это не вся архитектура, а только ее часть.

Как дома могут быть в разных стилях и мы отличим «сталинки» от «хрущевок», так и в архитектуре ПО тоже есть свои стили, которые задают основные идеи и принципы. Их много самых разных и их можно классифицировать тоже по-разному, часто у вас в реальной системе не чистый стиль, а какая-то смесь.

Авторы Head First Software Architecture рассказывают про несколько основных архитектурных стилей, которые являются краевыми случаями по двум характеристикам: модель развертывания и способ декомпозиции.

В реальности, повторюсь, может быть и чаще всего бывает что-то промежуточное.

В монолитной архитектуре мы разворачиваем все наши логические компоненты как одну сущность. И весь деплой происходит в один момент.

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

По способу декомпозиции авторы выделяют разбиение по техническим задачам и по бизнес-задачам, которые они решают.

Чтобы лучше понять идею, они приводят метафору ресторана и фудкорта. В ресторане каждая роль выполняет свою функцию. Было бы странно, если шеф-повар и готовил блюда, и убирал со столов. И это разделение по техническим задачам. А вот на фудкорте наоборот куча разных точек со своим профилем, где внутри выполняется все и сразу — и их удобнее разделить по бизнес-функциям.

#ZenTest
#книги