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

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

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

Шаблоны корпоративного уровня определяют «каркас» высокоуровневой архитектуры. К числу самых распространенных архитектурных шаблонов относятся архитектура, управляемая событиями (EDA, Event-Driven Architecture), сервис-ориентированная архитектура (SOA, Service-Oriented Architecture), ресурсно-ориентированная архитектура (ROA, Resource-Oriented Architecture) и конвейерная архитектура (pipeline architecture).

Шаблоны уровня приложения описывают дизайн приложения или подсистемы в контексте более крупной корпоративной архитектуры. К этой категории относятся хорошо известные шаблоны J2EE (например, Session Facade (фасад сессии) и Transfer Object (объект перемещения)), а также шаблоны, описанные в книге Мартина Фаулера (Martin Fowler) «Patterns of Enterprise Application Architecture»[22] (Addison-Wesley Professional).

Шаблоны интеграции играют важную роль в проектировании и описании концепций, связанных тем, как компоненты, приложения и подсистемы совместно используют информацию и функциональность. Вот некоторые примеры шаблонов интеграции: общий доступ к файлам, удаленные вызовы процедур, различные шаблоны передачи сообщений. Описания этих шаблонов см. http://www.enterpriseintegrationpatterns.com/eaipatterns.html.

Знание основных шаблонов из книги «банды четырех» «Design Patterns: Elements of Reusable Object-Oriented Software»[23] (Addison-Wesley Professional) обязательно для каждого архитектора. На первый взгляд может показаться, что эти шаблоны относятся к слишком низкому для архитектора программных продуктов уровню, однако они — часть лексикона, позволяющего архитекторам и разработчикам эффективно общаться.

Архитектор должен также знать и понимать суть различных антипаттернов. Антипаттерны (термин введен Эндрю Кенигом (Andrew Koenig)) представляют собой повторяемые процессы, приводящие к неэффективным результатам. Вот хорошо известные примеры антипаттернов: Analysis Paralysis (аналитический паралич), Design By Committee (разработка комитетом), Mushroom Management (управление грибами), Death March (путь камикадзе[24]). Знание этих шаблонов поможет вам избежать многих типичных ошибок. Список распространенных антипаттернов приведен по адресу http://ru.wikipedia.org/wiki/Антипаттерн.

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

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

Правила диктует контекст

Эдвард Гарсон

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

Но увы, ceci n’est pas une pipe.[25]

Один из наиболее ценных уроков, которые я вынес из опыта работы архитектором ПО, таков: контекст решает, а простота помогает. В практическом смысле это означает, что контекст — единственная сила, превосходящая простоту при принятии архитектурных решений.

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

Из чего состоит хорошая архитектура? Она является продуктом решений, которые принимаются в контексте противоречивых задач с различными приоритетами. Это означает, что самые важные решения иногда связаны не с тем, что следует включить в систему, а с тем, что из нее следует исключить. Ценность хорошей архитектуры заключается в умелом принятии решений (а ее продукт всего лишь отражает ваши намерения).

История предлагает нам немало интересных примеров влияния контекста на архитектуру. Мой любимый пример — выбор базы данных для программного обеспечения современного танка.[26] (Обычно выбор базы данных не имеет существенного значения для архитектуры системы; этот пример приводится лишь для пояснения.)

Когда пришло время выбирать базу данных, команда занялась изучением различных вариантов. Большинство баз данных оказалось способным обеспечить уровень производительности, необходимый для систем навигации и наведения на цель при быстром движении танка по пересеченной местности. Но потом команда неожиданно выяснила, что выстрел из орудия создает сильный электромагнитный импульс, который вызывает сбой бортовых систем — и, конечно, базы данных! На современном поле боя танк с неработающим программным обеспечением буквально теряет связь с внешним миром. В этом контексте решающим фактором при выборе базы данных стало время восстановления, и лучшими показателями в этом отношении обладала на тот момент InterBase, поэтому для танка Ml Abrams была в итоге выбрана именно эта база данных.[27]

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

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

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

Гномы, эльфы, волшебники и короли

Эван Кофски

В романе Нила Стивенсона «Cryptonomicon»[28] Рэнди Уотерхауз излагает свою классификацию рас, с которыми ему доводилось встречаться. Гномы — трудяги, корпящие над произведениями искусства во мраке своих пещер. Они повелевают огромными силами, способными перемещать горы и преображать ландшафт, и славятся своим мастерством. Эльфы отличаются изысканностью и высочайшей культурой; они проводят свои дни за созданием новых прекрасных волшебных предметов. Они до такой степени талантливы, что даже не сознают, насколько сверхъестественными представляются эти предметы другим расам. Волшебники наделены огромной силой, но, в отличие от эльфов, много знают о магии, разбираются в ее природе и возможностях и применяют ее максимально действенно и эффектно. Однако существует и четвертый тип, о котором Уотерхауз упоминает кратко, не останавливаясь для подробного описания. Это короли — мудрые правители, которые знают, как управлять всеми прочими.

Архитектор в некотором роде относится к «королевскому роду». Он должен хорошо понимать все остальные «расы» и