Помните картинку “как нарисовать сову”? Мол рисуем две окружности и добавляем все остальное. То же самое происходит с дизайном системы. Берутся требования и… превращаются в архитектуру системы. И совершенно непонятно почему тут ASP .Net MVC, тут Message Queue, а тут availability кластер. И есть ли обоснование для кластера и MQ в требованиях? Тоже непонятно.

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

А потому, что исходя из требований, получается именно такая система: простое, понятное, 3-tier, монолитное приложение, с использованием стандартных средств платформы .Net.

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

Как обычно, у меня есть презентация на тему статьи, поэтому вы можете сразу обратиться к ней:

Зачем нужна архитектура

Зайти я хочу издалека. С цели: а зачем нам нужна эта самая архитектура? У нас ведь agile, нам не нужна архитектура, оно само появится!

Я не буду никого переубеждать, я хочу показать лучшее, на мой взгляд, определение архитектуры из книги Software Architecture in Practice (3rd Edition):

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both

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

Например заказчик хочет понять стоимость системы и размер команд. Как оцениваем? Бьем проблему на части и оцениваем отдельно. Для большой системы изначальное разбиением будет как раз логической диаграммой. Причем конкретные сроки и размер команд могут поступать на вход цикла проектирования, меняя структуру системы. Но это так, рассуждения. Без конкретной ситуации практически бесполезные.

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

Как же спроектировать архитектуру системы?

Процесс это выглядит так:

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

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

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

На последующих этапах мы добавляем остальные нефункциональные требования и уточняем/усложняем модель. Например нам нужна высокая доступность и выдерживание высокой нагрузки – мы добавляем кэш, кластер или вэб ферму. Поток данных от внешней системы идет непрерывно и асинхронно – мы добавляем очередь сообщений. Внешняя система ненадежная или не выдержит нагрузку нашего приложения – мы добавляем еще одну систему в решение, которая будет выкачивать данные и отдавать сохраненные локально данные другим нашим системам. Нам требуется мощная аналитика и репортинг с которыми база данных и .net платформа не справятся (или справятся, но это будет дорого) – добавляем BI решение с, возможно, отдельным интерфейсом для роли Reporting User.

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

Что дальше?

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

В заключение я хочу порекомендовать C4 модель Саймона Брауна (Simon Brown). Именно оттуда была взята Solution Context Diagram (в презентации есть дополнительные ссылки). И книгу Software Architecture in Practice (3е издание). В интернете найти его нельзя, только купить. О книге можно получить представление из серии слайдов, составленных самими авторами.

А как вы проектируете систему? Есть ли у вас (относительно) формализованный подход или вы творите архитектуру основываясь на опыте и внутреннем чутье? Можете поделиться вашим подходом?