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