Как архитектор понимает, какие свойства вообще нужны системе? Есть три источника, откуда это можно взять: планы бизнеса, конкретные требования и неявные особенности предметной области.

Рассмотрим на примере интернет-магазина.

Планы бизнеса

Это то, что бизнес говорит вслух. Задача архитектора — перевести «хотелки» на язык архитектуры. Вот несколько рабочих связок:

- Слияния и поглощения = интероперабельность, масштабируемость, адаптируемость.

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

- Горят сроки выпуска = производительность, доступность, отказоустойчивость, тестируемость, развертываемость.

Продукт надо запустить к Черной пятнице, а значит нужна развертываемость (катить релизы быстро и часто) и тестируемость (не тратить дни на ручную проверку каждой сборки).

- Конкурентоспособность = гибкость, тестируемость, доступность, масштабируемость.

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

- Жмут сроки и бюджет = простота и реализуемость.

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

Тут важно держать список как можно короче, иначе система усложнится до предела, а это последнее, что нужно в самом начале.

Также нашел небольшой лайфхак: чтобы реально уложиться в сроки, лучше всего работает связка «гибкость + тестируемость + развертываемость».

Конкретные требования

Это то, что уже записано в ТЗ: сколько ожидается пользователей и куда все будет расти. Но есть нюанс - архитектор должен иметь опыт в предметной области, чтобы предвидеть все, что влияет на систему и особенно на ее структуру.

Свойства из требований делятся на две группы:

Явные — те, что бросаются в глаза сразу, например:

- «В Черную пятницу трафик вырастет в 20 раз» - всплески запросов

- «Оплата идет через внешний банк, который иногда тормозит» - походы во внешние сервисы

- «Пользователь уходит, если страница грузится дольше 3 секунд» - скорость загрузки

Неявные — не так заметны, но именно они часто решают судьбу проекта:

- доступность - «магазин упал на 2 часа в пик распродажи», а это прямые потери и злые клиенты

- надежность - «заказ оплачен, но не создался в системе», клиент заплатил в никуда

- безопасность - «утекли данные карт», штрафы и конец репутации.

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

Неявные особенности предметной области

Это самое коварное, то, что никто не проговаривает и не пишет в ТЗ, потому что для отрасли это «само собой разумеется». Именно эти свойства архитектор обязан знать сам из опыта в домене.

Для интернет-магазина это могут быть например:

- Требования регулятора, когда данные карт нужно хранить по стандарту

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

- Обязательные сценарии. Возвраты и отмены заказов неотъемлемая часть e-comm, хотя в первой версии ТЗ про них легко забывают.

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

Итог

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

Задача архитектора собрать свойства из всех трех, а затем вычислить, что реально критично, и защитить это в первую очередь.

#архитектура #softwarearchitecture #systemdesign #архитектурныесвойства #it #проектирование