База данных последний страж, охраняющий ваши драгоценные данные. Прикладной уровень, эфемерный по своей природе, не может следить за собой сам. Для того чтобы база данных обеспечивала необходимую защиту, модель данных нужно спроектировать так, чтобы она отвергала неподходящие данные и не позволяла создавать отношения, не имеющие смысла. Ключи, отношения по внешнему ключу и ограничения предметной области, описанные в схеме, лаконичны, понятны, легко проверяются и в конечном итоге самодокументируемы. Правила предметной области, закодированные в модели данных, также имеют физический, долгосрочный характер; они не теряются при изменениях в логике приложения.
Чтобы извлечь из реляционной базы данных максимальную пользу, то есть сделать ее полноценной частью приложения, а не просто хранилищем данных приложения, необходимо с самого начала хорошо понимать, что же вы создаете. По мере развития вашего продукта будет совершенствоваться и уровень данных, но в каждой фазе развития он должен сохранять свой статус Крепости. И тогда вы сможете довериться ему и с уверенностью возложить на него ответственность за перехват ошибок с других уровней приложения и он вас не разочарует.
Дэн Чак (Dan Chak) директор по разработке ПО в CourseAdvisor Inc., компании Washington Post. Является автором книги «Enterprise Rails» (O'Reilly).
Руководствуйтесь неопределенностью Кевлин Хенни
Одно из самых простых и конструктивных определений архитектуры дал Гради Буч (Grady Booch): «Любая архитектура является результатом проектирования, но не любое проектирование направлено на создание архитектуры. Архитектура
служит представлением важных проектировочных решений, формирующих систему, причем важность здесь определяется стоимостью изменений». Отсюда следует, что эффективной является та архитектура, которая в общем случае снижает важность решений, принятых в ходе проектирования. Неэффективная архитектура эту важность увеличивает.
Если проектировочное решение может повести по одному из двух путей, архитектор должен отступить на шаг. Вместо того чтобы выбирать между вариантами А и Б, он должен подумать над другим вопросом: «Как спроектировать решение, чтобы снизить важность выбора между А и Б?». В этой ситуации интересен не выбор между А и Б, а сам факт существования этого выбора (а также то, что правильный выбор необязательно очевиден или неизменен).
Иногда архитектору приходится ходить кругами, прежде чем его озарит и он распознает возникшую дихотомию. Вы стоите у доски, обсуждая (весьма энергично) разные варианты с коллегой? Вы задумчиво бормочете «М-м-м» и «Э-э-э» над кодом, бесконечно перебирая возможные реализации? Когда новое требование или уточнение существующего требования ставит под сомнение разумность текущей реализации, перед вами неопределенность. Как реагировать на нее? Подумайте, как с помощью разделения или инкапсуляции изолировать принимаемое решение от кода, который в конечном итоге зависит от этого решения. Альтернативой этому часто становится невнятный код, который, словно нервничающий человек на собеседовании, бормочет что-то невразумительное и пытается компенсировать неуверенность множеством догадок и общих фраз. А если выбор делается с твердой, но необоснованной уверенностью, то проект на полной скорости и без оглядки сворачивает на неверный путь.
Часто возникает искушение принять «решение ради решения». В таких ситуациях вам поможет опционное мышление. Если существует неопределенность относительно различных путей, по которым может пойти разработка системы, примите решение не принимать решение. Отложите конкретное решение до того момента, когда его можно будет принять более ответственно на основании реальных знаний, но не слишком надолго, чтобы не попасть в ситуацию, когда эти знания уже бесполезны.
Архитектура и процесс разработки тесно переплетены; это главная причина, по которой архитектор должен отдавать предпочтение таким циклам разработки и архитектурным подходам, которые имеют эмпирическую природу и обеспечивают обратную связь, чтобы конструктивно использовать неопределенность для деления на части самой системы и графика ее разработки.
Биография автора приведена ранее.
Проблемы могут быть больше, чем их отражение в зеркале Дэйв Куик
Это случается по разным причинам:
Проблемы, которые кажутся тривиальными на ранней стадии проекта, становятся критическими тогда, когда их уже поздно исправлять. История про сварившуюся
лягушку, вероятно, является преувеличением, однако она прекрасно иллюстрирует то, что творится во многих проектах.