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

Архитектор ПО может почерпнуть из этой истории много полезного и учесть этот печальный опыт при проектировании архитектуры программных продуктов. Попытка выполнить все требования сразу (как в случае с «Вазой») создает неустойчивую архитектуру, которая не решает толком ни одну из поставленных задач. Хороший пример такого рода — требование заставить сервис-ориентированную архитектуру (SOA, service-oriented architecture) заодно функционировать в качестве решения «точка-точка». Обычно это вынуждает обходить различные уровни абстракции, создаваемые подходом SOA, и в результате возникает архитектура, напоминающая блюдо спагетти из итальянского ресторана. В распоряжении архитектора имеется несколько инструментов для определения тех компромиссов, на которые приходится идти при проектировании архитектур. Два популярных метода такого рода — АТАМ (Architecture Tradeoff Analysis Method) и CBAM (Cost Benefit Analysis Method). Дополнительную информацию об АТАМ и СВАМ можно найти на сайте SEI (Software Engineering Institute).

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

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

Огромная популярность методологий гибкой разработки привела многих к мысли, что приложения можно (и даже предпочтительно!) проектировать по ходу работы. Эпоха предварительного написания сложных, исчерпывающих технических спецификаций ушла навсегда! Новая школа призывает поставлять продукт рано и часто. Одна строка эксплуатируемого кода полезнее 10 строк у вас в голове. Звучит слишком хорошо, чтобы быть правдой… во всяком случае в том, что касается данных.

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

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

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

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

Дэн Чак (Dan Chak) — директор по разработке ПО в CourseAdvisor Inc., компании Washington Post. Является автором книги «Enterprise Rails» (O'Reilly).

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

Одно из самых простых и конструктивных определений архитектуры дал Гради Буч (Grady Booch): «Любая архитектура является результатом проектирования, но не любое проектирование направлено на создание архитектуры. Архитектура служит представлением важных проектировочных решений, формирующих систему, причем важность здесь определяется стоимостью изменений». Отсюда следует, что эффективной является та архитектура, которая в общем случае снижает важность решений, принятых в ходе проектирования. Неэффективная архитектура эту важность увеличивает.

Если проектировочное решение может повести по одному из двух путей, архитектор должен отступить на шаг. Вместо того чтобы выбирать между вариантами А и Б, он должен подумать над другим вопросом: «Как спроектировать решение, чтобы снизить важность выбора между А и Б?». В этой ситуации интересен не выбор между А и Б, а сам факт существования этого выбора (а также то, что правильный выбор необязательно очевиден или неизменен).

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