Эффективные способы описания архитектуры

Споры о том, как описывать архитектуру не прекращались никогда и тому есть простое объяснение: правильного способа не существует, но существуют отличные способы, применимые для различных продуктов на различных стадиях развития и различных команд и их структур

Прежде чем переходить к перечню практик, детальное описание которых будет дано в последующих статьях цикла, зададимся вопросом:

«Зачем?»

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

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

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

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

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

Общий подход

Прежде чем перейти к содержательной части, попробуем разложить способы описания архитектуры по удобным категориям, а именно: по простоте/сложности внесения изменений и простоте/сложности масштабирования (т.е. насколько просто или сложно распространять информация об изменениях на всех заинтересованных лиц).

Для этого ответим на два вопроса:

1. Как часто приходится принимать или изменять архитектурные решения?
2. На какое количество людей мы должны распространить информацию о  принятых инженерных решениях?

И посмотрим на ось вариативности:

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

Первая группа методов включает в себя:

• сторителлинг
• метафору системы (практика экстремального программирования)  и
• архитектурные эскизы

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

Первоначальный эскиз может выглядеть следующим образом:

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

В эту группу методов, которые чуть сложнее менять, но уже значительно проще масштабировать, входят:

• Архитектурное хайку (George Fairbanks, автор книги Just Enough Software Architecture),
• Журнал архитектурных решений
• Фитнес-функции

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

Формальные методы включают в себя традиционные архитектурные документы и формальные модели. Эти документы обычно крупнее и требуют больших затрат на создание и поддержку, а модели — детально проработаны и точны.

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

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

Завершим вводную статью цитатой Герберта Саймона: «Solving a problem simply means representing it so as to make the solution transparent.». Перефразируя применительно к теме статьи: «Решение проблемы — это взгляд на неё с такой точки зрения, что решение становится очевидным».

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