Базовые элементы архитектурного фреймворка

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

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

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

Как видите, архитектура системы — это не точка на прямой, а точка в многомерном пространстве (согласно авторам — в 4-мерном пространстве). В этом и кроется причина, по которой мы не можем дать архитектуре односложное определение, но можем описать её с разных сторон, одновременно отвечая на вопрос, почему решение именно такое, какое есть. Невозможно составить полное представление об архитектуре системы только по одному измерению, их нужно рассматривать в комплексе.

Структура системы (structure of the system) — тип используемого архитектурного стиля (или стилей). Например, микросервисная, многоуровневая, микроядерная и т.д. Стиль задаёт структуру, но не отвечает на вопрос “почему”. Без всего остального — это просто прямоугольники и стрелки.
Свойства архитектуры (architecture characteristics) — важнейшие черты системы, определяющие критерии успеха. Свойства не связаны с функциональными возможностями системы, но нужны для её корректной работы. Авторы называют их “словами с окончанием -ость” (англ. -ility): масштабируемость, производительность, доступность, безопасность и т.д.
Архитектурные решения (architecture decisions) — правила построения системы и ограничения. Например, “доступ к базе данных возможен только с уровня бизнес-логики”. Естественно, что решения не высечены в камне, и их можно и нужно подвергать сомнению. Главное, чтобы вокруг всего этого был выстроен процесс архитектурного контроля.
Принципы проектирования (design principles) — верхнеуровневые установки и рекомендации. Например, “для повышения производительности и ослабления связанности отдавать предпочтение асинхронному взаимодействию”; “для улучшения наблюдаемости использовать трассировку всех публичных методов сервиса” и т.п.

Как видите, все эти измерения взаимосвязаны: изменения в одном измерении, скорей всего, отразится в других. Задача архитектора — найти наиболее устойчивое положение в пространстве. И это положение, очевидно, будет совокупностью компромиссов, о которых все так любят говорить. Но главное, что поиск такого положения будет формировать целостный взгляд, структурированный и осознанный ответ на вопрос “почему”.

Как это всё связано с практикой и при чём тут фреймворк? Посмотрите на свою систему сквозь призму этих измерений. Для каждого ограниченного контекста определите 3 самых важных архитектурных свойства. Если у каждого контекста свой набор свойств, а у вас “монолит”, тогда вам, возможно, следует задуматься о декомпозиции. Затем посмотрите на свои архитектурные решения и проверьте, способствуют ли они достижению выбранных свойств. А структура и принципы проектирования работают на общее дело? Я думаю, что вы уже поняли, как это работает.

Резонный вопрос: “Почему только 4 измерения? Можно больше или меньше?” Больше, наверное, можно, меньше — не думаю. Главное, чтобы за всем этим вы видели технологию, которая позволяет в работе перейти от интуиции к системности.

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

Вопрос: Не совсем понятно, чем архитектурные решения отличаются от принципов проектирования.

Ответ:

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

Следуя этой концепции они определяют архитектурные решения как то, что влияет на структуру приложения или системы, включая выбор технологических средств, но при условии, что всё это влияет на выбранные архитектурные свойства, способствует их достижению. Также подмечают, что архитектурные решения подразумевают сбор информации для его обоснования, а также описание решения, необходимое и достаточное, чтобы убедить всех ответственных в его правильности. Говоря простым языком, архитектурное решение - это описание способа реализации чего-то в заданном прикладном контексте, но при условии, что это такое решение поддерживает определенное (выбранное) архитектурное свойство. Последнее дополнение проводит тонкую грань между архитектурным решением и техническим. Таким образом, выбор конкретной технологии не всегда архитектурное решение, но и не всегда техническое. Также даётся уточнение, что к архитектурно значимым решениям относятся те, которые влияют на структуру (1-е измерение); архитектурные свойства (2-е измерение), иногда называемые “нефункциональными требованиями”; зависимости (то, что определяет связанность между компонентами); API компонентов и их версионирование.

А вот принципы проектирования - это руководство для разработчиков (guideline), рекомендации. Это уже не жёсткие правила, а какие-то “общие правила игры”. Архрешения не могут охватить всевозможные ситуации, поэтому заранее договариваемся о каких-то общих условиях игры. Например, можем сказать, что для при разработке придерживаемся SOLID-принципов; ведём разработку в стиле Domain-Driven Design; пишем приёмочные тесты, подменяя in/out-порты на заглушки; для тестирования публичного API используем контрактное тестирование с помощью Pact и т.д. Если архрешение задаёт чёткое правило (закон) в заданных условиях, то принципы задают общие правила поведения в большинстве возможных ситуаций.

Можно ли принципы проектирования оформить в виде архитектурного решения (ADR)? Я думаю, что вполне можно, но, как мне кажется, их нужно структурно отделить. Например, поместить в какой-то отдельный каталог типа commons. Тогда новый член команды сможет быстро пройтись по базовым принципам, принятым в проекте, а не перебирать всю историю принятых решений.

Нужно ли отделять архитектурные решения от технических? Или же все решения хранить в общей куче? В идеале, лучше отделять, чтобы чётко видеть то, что действительно влияет на архитектурные свойства. С другой стороны, такое разделение требует от нас максимальной дисциплинированности и педантичности, что на практике трудно достижимо. Наверное, компромиссным решением было бы введение в описание какого-то “уровня важности” (перечисление). И при выборе уровня важности можно было бы давать пояснение, что он значит. Я видел, что в крупных компаниях есть такая категоризация и отдельный процесс согласования решений для каждого уровня важности.

Понравилась статья?