97 этюдов для архитекторов программных систем - Нил Форд

Биография автора приведена ранее.

Проверяйте решения на прочность по ключевым характеристикам

Стивен Джонс

Изначально архитектура приложения Формируется на основании заданных бизнес-требований, выбранных или уже применяемых технологий, диапазона производительности, ожидаемых объемов данных и финансовых ресурсов, выделенных для построения, развертывания и управления системой. Решение, каким бы оно ни было, должно соответствовать требованиям из этого набора либо превосходить их — и при этом успешно работать в современных условиях (иначе это попросту не решение).

Теперь возьмите свое решение и посмотрите, какие проблемы появятся, если «растянуть» ключевые характеристики.

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

«Растяжение» ключевых характеристик поможет вам:

• Понять, выдержит ли запланированная инфраструктура такие изменения и где именно заложены ограничения. Если работа инфраструктуры будет нарушена, этот процесс позволяет узнать, где именно произойдут нарушения. Далее можно сообщить полученную информацию владельцу приложения или же учесть возможность обновления при покупке инфраструктуры.

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

• Убедиться в том, что механизмы доступа к данным останутся работоспособными при масштабировании системы. Решение, работающее с недельным объемом данных, может не справиться с объемом, накопленным за полгода.

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

• Убедиться, что приложение сможет нормально восстанавливаться после сбоев при возрастании объема данных и/или разделении данных в пределах расширенной инфраструктуры.

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

Стивен Джонс (Stephen Jones) проектирует решения для Tier-lTelco Billing и сопутствующие крупномасштабные процессы для таких компаний, как Telstra и Optus (Австралия), а также AT&T (США). В частности, он занимался исходной реализацией систем тарификации Telco, перепроектированием системы опротестования счетов и борьбы с фальсификациями и более двух лет управлял службой круглосуточной поддержки Telstra.

Проектируйте только то, что можете запрограммировать

Майк Браун

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

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

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

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

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

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

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

Как же архитектор должен подходить к освоению новых инфраструктур, шаблонов и серверных платформ? Об этом вам расскажет этюд «Архитектор — прежде всего разработчик».

Биография автора приведена ранее.

«Что значит имя?», или Как роза превращается в капусту

Сэм Гардинер

Я случайно подслушал разговор архитекторов, которые принимали решение о необходимости дополнительных уровней в их архитектуре. Они были правы, но, как это нередко случается, подошли к делу немного не с той стороны. Они пытались создать инфраструктуру, которая включала бы в себя бизнес-логику. Вместо того чтобы решать конкретную задачу, они задумали создать инфраструктуру, которая инкапсулирует базу данных и создает объекты. И при этом она должна была использовать объектно-реляционные отображения. И сообщения. И веб-службы. И должна была делать массу других Классных Штук.

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

В нашем конкретном случае быстрый просмотр истории версий исходного кода выявил всю глубину проблемы. Конечно, в нем оказалось множество пустых «реализаций» интерфейсов! Но самое смешное, что даже без нормального кода имена уже менялись трижды. Сначала было выбрано имя ClientAPI (причем под «клиентом» имелся в виду заказчик, а не клиент в контексте модели «клиент-сервер»), а последняя версия называлась ClientBusinessObjects. Воистину замечательное имя: туманное, предельно широкое и сбивающее с толку.

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