Дополнительные источники

Электронная версия списка используемых источников доступна по адресу http://www.microsoft.com/architectureguide.

Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2004.

Nilsson, Jimmy. Applying Domain-Driven Design and Patterns: With Examples in C# and NET. Addison-Wesley, 2006.

Больше информации об архитектурных стилях можно найти в следующих источниках:

«An Introduction To Domain-Driven Design» (Введение в проектирование на основе предметной области) по адресу http://msdn.microsoft.com/enus/magazine/dd419654.aspx.

«Domain Driven Design and Development in Practice» (Проектирование и разработка на основе предметной области на практике) по адресу http://www.infoq.com/articles/ddd- in-practice.

«Fear Those Tiers» (Боязнь ярусов) по адресу http://msdn.microsoft.com/enus/library/cc168629.aspx.

«Layered Versus Client-Server» (Сравнение многоуровневой архитектуры с архитектурой клиент-сервер) по адресу http://msdn.microsoft.com/en-us/library/bb421529.aspx.

«Message Bus» (Шина сообщений) по адресу http://msdn.microsoft.com/enus/library/ms978583.aspx.

«Microsoft Enterprise Service Bus (ESB) Guidance» (Руководство по Microsoft Enterprise Service Bus (ESB)) по адресу http://www.microsoft.com/biztalk/solutions/soa/esb.mspx.

«Separated Presentation» (Отделение представления) по адресу http://martinfowler.com/eaaDev/SeparatedPresentation.html.

«Services Fabric: Fine Fabrics for New-Era Systems» (Сервисы: превосходные решения для систем новой эры) по адресу http://msdn.microsoft.com/en-us/library/cc168621.aspx.

4

Методика построения архитектуры и дизайна

Обзор

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

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

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

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

Исходные данные, выходные данные и этапы проектирования

Исходные данные проектирования помогают формализовать требования и ограничения, которые должна реализовать создаваемая архитектура. Обычно исходными данными являются варианты использования и сценарии поведения пользователя, функциональные требования, нефункциональные требования (включая параметры качества, такие как производительность, безопасность, надежность и другие), технологические требования, целевая среда развертывания и другие ограничения.

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

Рис. 3

Основные этапы итеративного процесса проектирования архитектуры

Этими этапами, которые более подробно рассматриваются в следующих разделах, являются:

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

2.Основные сценарии. Используйте основные сценарии, чтобы сосредоточиться на том, что имеет первостепенное значение, и проверяйте возможные варианты архитектур на соответствие этим сценариям.

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

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

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

Такой процесс создания архитектуры предполагает итеративный и инкрементный подход. Сначала создается возможный вариант архитектуры – обобщенный дизайн, который может тестироваться по основным сценариям, требованиям, известным ограничениям, параметрам качества и Архитектурной Базе1. В ходе доработки варианта архитектуры, выявляются дополнительные детали и сведения о дизайне, результатом чего становится расширение основных сценариев, корректировка общего представления приложения и подхода к решению проблем.

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

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

Определение целей архитектуры

Цели архитектуры – это задачи и ограничения, очерчивающие архитектуру и процесс проектирования, определяющие объем работ и помогающие понять, когда пора остановиться. Рассмотрим ключевые моменты в определении целей архитектуры:

Начальное определение задач архитектуры. От этих задач будет зависеть время,

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

1 Architecture Frame – термин предложенный авторами руководства, означает коллекцию архитектурных аспектов на которые нужно акцентировать внимание, а также шаблонов и инженерных подходов. Подробнее по адресу http://blogs.msdn.com/jmeier/archive/2008/09/22/architecture-frame.aspx (прим. технического редактора).