97 этюдов для архитекторов программных систем - Нил Форд
Архитектор Янус
Дэвид Бартлетт
У древних римлян Янус считался богом начала и завершения, дверей и проходов. Обычно его изображали с двумя головами, направленными в разные стороны; этот символ часто встречается на монетах и в кино. Янус символизирует переходы и изменения в жизни — рождение, вступление в брак, достижение зрелости — от прошлого к будущему, от юности к старости.
Способность Януса смотреть вперед и назад, видеть прошлое и будущее является исключительно ценным навыком как для архитектора программного обеспечения, так и для архитектора-строителя. Архитектор стремится объединить реальность со своим представлением о ней, прошлые достижения — с планами на будущее, ожидания руководства — с ограничениями разработки. Наведение таких мостов — важнейшая часть работы архитектора. Часто у архитектора возникает чувство, что в своем стремлении довести проект до завершения ему приходится преодолевать пропасти, которые созданы воздействием сил, направленных в противоположные стороны. Это могут быть, например, простота в использовании и безопасность или соответствие текущим бизнес-процессам и ориентация на перспективу, обрисованную руководством. У хорошего архитектора должно быть «две головы», способные удерживать две разные идеи или концепции, две разные цели или точки зрения, чтобы он мог создать продукт, удовлетворяющий все заинтересованные стороны проекта.
Обратите внимание: у Януса две головы, а не просто два лица. Иначе говоря, он обладает дополнительной парой ушей и глаз, что повышает его осведомленность и восприимчивость. Хороший IT-архитектор должен быть превосходным слушателем и аналитиком. Понимание причин, по которым осуществляются инвестиции, жизненно важно для определения целей и представлений руководства о будущем организации. Умение оценивать технические навыки вашего персонала в области проектирования и используемых в проекте технологий поможет сформировать подходящие пары для обучения и работы. Знание о том, какие решения с открытым кодом можно использовать в сочетании с теми или иными коробочными коммерческими программами, заметно сократит бюджет и сроки реализации проекта. Хороший архитектор должен разбираться в этих и многих других составляющих процесса разработки и уметь ставить их себе на службу, чтобы обеспечить успех проекта в целом.
Некоторые начальники ожидают от своих архитекторов едва ли не божественных способностей, но это не то, что я имел в виду, сравнивая архитектора с божеством. Хороший архитектор открыт для новых идей, инструментов и способов проектирования, способствующих прогрессу проекта, развитию команды или профессиональному совершенствованию; он не желает тратить большую часть своего времени на совещания с руководством или собственноручное написание кода; он должен распознавать ценные идеи и создавать атмосферу, способствующую их созреванию. Успеха в проектировании может добиться только подлинно открытый ум — ум, способный в ходе выполнения проекта находить точку равновесия множества противоборствующих сил. Каждый архитектор стремится завершить свой проект и обеспечить успех своей команды. Лучшие из архитекторов создают системы, которые выдерживают проверку временем, поскольку способны сохранять работоспособность и развиваться по мере роста организации и изменений в технологиях. Такие архитекторы прислушиваются к мнениям других, анализируют и перерабатывают свои процессы, методы и подходы к проектированию; они прилагают особые усилия, чтобы их продукты устояли перед неизбежными изменениями и переходами.
К такому образу мышления должны стремиться мы, архитекторы. Это легче сказать, чем сделать. Подобно Янусу, архитектор должен стать хранителем дверей и проходов, прокладывать мосты между старым и новым; он должен объединять творческий подход с надежным техническим фундаментом, чтобы, выполняя сегодняшние требования, быть готовым к завтрашним переменам.
Биография автора приведена ранее.
В центре внимания архитектора — границы и интерфейсы
Эйнар Ландре
С тех пор как лорд Нельсон уничтожил французский и испанский флоты при Трафальгаре в 1805 году, принцип «разделяй и властвуй» стал главной мантрой для решения сложных комплексных задач. Другой, более знакомый термин с таким же смыслом — разделение ответственности (separation of concern). Разделение ответственности ведет к инкапсуляции, а инкапсуляция способствует выделению границ и интерфейсов.
Если смотреть на задачу глазами архитектора, наиболее сложная ее часть — поиск естественных мест для формирования границ и определение подходящих интерфейсов, нужных для создания работоспособной системы. Это особенно трудно сделать в крупных корпоративных системах, где естественных границ зачастую очень мало, а различные предметные области тесно переплетены. В подобных ситуациях отчасти помогают традиционные принципы вроде «Минимизируй связанность, увеличивай сцепление» (minimize coupling, maximize cohesion) и «Не разрезай там, где нужен интенсивный обмен информацией», однако они ничего не говорят о том, как простым путем донести информацию о задачах и потенциальных решениях до заинтересованных сторон.
Здесь на помощь приходит концепция ограниченных контекстов и карт контекстов, описанная Эриком Эвансом в книге «Domain-Driven Design» (Проектирование на основе предметной области) (Addison-Wesley Professional). Ограниченным контекстом (bounded context) называется область уникального определения модели или понятия; на диаграммах она изображается в виде «облачка» с содержательным именем, определяющим его роль или задачу в предметной области. Например, система транспортировки может содержать такие контексты, как «Отгрузка», «Планирование отгрузки» и «Перемещения в пределах порта». В других предметных областях возникнут другие имена.
После того как вы выделили ограниченные контексты и нанесли их на доску, наступает следующий этап — обозначение связей между контекстами. Эти связи могут отражать организационные, функциональные или технические зависимости. В результате создается карта контекстов (context тар) — совокупность контекстов и интерфейсов между ними.
Карта контекстов становится в руках архитектора полезным инструментом, который помогает сосредоточиться на том, какие компоненты следует держать вместе, а какие необходимо отделить друг от друга; другими словами, наглядно реализуется принцип «разделяй и властвуй». Эта техника может быть с легкостью использована как для документирования и анализа текущей ситуации, так и для перепроектирования с целью создания системы, обладающей слабой связанностью, высоким сцеплением и четко определенными интерфейсами.
Биография автора приведена ранее.
Поддерживайте разработчиков
Тимоти Хай
Сказать обычно проще, чем сделать; уж что-что, а говорить архитекторы умеют. Чтобы ваши слова не превращались в пустое сотрясание воздуха (основной метод возведения воздушных замков), вам понадобится хорошая команда разработчиков. Как правило, роль архитектора состоит в том, чтобы накладывать ограничения, но у вас есть также возможность эти ограничения снимать. Сделайте все от вас зависящее, чтобы развязать руки разработчикам.
Удостоверьтесь, что у разработчиков есть все нужные инструменты. Инструментарий не должен быть навязан сверху — он должен быть вдумчиво выбран, с тем чтобы у разработчиков под рукой всегда было все необходимое. Рутинную работу следует по возможности автоматизировать. Кроме того, не жалейте средств на то,
