Итак, архитектор разобрался в качественных требованиях заинтересованных сторон проекта. Что он должен делать после этого? Проанализировать компромиссы. Например, шифрование сообщений повышает безопасность, но ухудшает производительность. Конфигурационные файлы улучшают способность к изменениям, но могут снизить удобство пользования (если мы не сможем организовать проверку правильности конфигурации). Будем ли мы использовать стандартный формат таких файлов (например, XML), или изобретем свое собственное представление? В ходе проектирования архитектуры системы приходится принимать много непростых компромиссных решений.
Следовательно, работа архитектора должна начаться с общения с заинтересованными сторонами. В ходе этого общения архитектор выясняет качественные требования и ограничения, назначая им приоритеты. Почему бы не начать с функциональных требований? У любой системы обычно существует много возможных декомпозиций. Например, если выбрать в качестве отправной точки модель данных, вы придете к одной архитектуре; если начать с модели бизнес-процессов, архитектура может быть совершенно другой. В крайнем случае декомпозиция вообще отсутствует, а система разрабатывается как монолитный блок программного кода. Такой подход обеспечит выполнение всех функциональных требований, но, скорее всего, в этом случае не будут выполняться качественные требования – способность к изменениям, удобство сопровождения и масштабируемость.
Related posts: