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

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