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

В центре внимания архитектора — границы и интерфейсы Эйнар Ландре

С тех пор как лорд Нельсон уничтожил французский и испанский флоты при Трафальгаре в 1805 году, принцип «разделяй и властвуй» стал главной мантрой для решения сложных комплексных задач. Другой, более знакомый термин с таким же смыслом — разделение ответственности (separation of concern). Разделение ответственности ведет к инкапсуляции, а инкапсуляция способствует выделению границ и интерфейсов.

Если смотреть на задачу глазами архитектора, наиболее сложная ее часть — поиск естественных мест для формирования границ и определение подходящих интерфейсов, нужных для создания работоспособной системы. Это особенно трудно сделать в крупных корпоративных системах, где естественных границ зачастую очень мало, а различные предметные области тесно переплетены. В подобных ситуациях отчасти помогают традиционные принципы вроде «Минимизируй связанность, увеличивай сцепление» (minimize coupling, maximize cohesion) и «Не разрезай там, где нужен интенсивный обмен информацией», однако они ничего не говорят о том, как простым путем донести информацию о задачах и потенциальных решениях до заинтересованных сторон.

Здесь на помощь приходит концепция ограниченных контекстов и карт контекстов, описанная Эриком Эвансом в книге «Domain-Driven Design» (Проектирование на основе предметной области) (Addison-Wesley Professional). Ограниченным контекстом (bounded context) называется область уникального определения модели или понятия; на диаграммах она изображается в виде «облачка» с содержательным именем, определяющим его роль или задачу в предметной области. Например, система транспортировки может содержать такие контексты, как «Отгрузка», «Планирование отгрузки» и «Перемещения в пределах порта». В других предметных областях возникнут другие имена.

После того как вы выделили ограниченные контексты и нанесли их на доску, наступает следующий этап — обозначение связей между контекстами. Эти связи могут отражать организационные, функциональные или технические зависимости. В результате создается карта контекстов (context тар) — совокупность контекстов и интерфейсов между ними.

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

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

Поддерживайте разработчиков Тимоти Хай

Сказать обычно проще, чем сделать; уж что-что, а говорить архитекторы умеют. Чтобы ваши слова не превращались в пустое сотрясание воздуха (основной метод возведения воздушных замков), вам понадобится хорошая команда разработчиков. Как правило, роль архитектора состоит в том, чтобы накладывать ограничения, но у вас есть также возможность эти ограничения снимать. Сделайте все от вас зависящее, чтобы развязать руки разработчикам.

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

Проследите за тем, чтобы разработчики обладали необходимыми навыками. Если разработчикам необходимо обучение, позаботьтесь о том, чтобы они могли его пройти. Покупайте книги и поощряйте активные обсуждения технологий. Трудовая жизнь разработчика должна быть занята практической деятельностью, но это не должно мешать активному повышению квалификации. Если вы располагаете достаточными средствами, отправляйте свою команду на технические презентации и конференции. Если нет — подключите команду к техническим спискам рассылки и следите за бесплатными мероприятиями в своем городе. По возможности участвуйте также в процессе отбора разработчиков. Ищите тех, кто жаждет учиться, у кого есть «искра» технической одаренности (но убедитесь в том, что они способны работать в команде…). Трудно добиться чего-то выдающегося от группы безликих работяг.