HLD, LLD и рабочие документы полезны тогда, когда описывают одну систему на разных уровнях подробности. Эти обозначения не задают универсальную обязательную структуру. В начале проекта нужно договориться, какие решения относятся к каждому уровню и как команда проверяет переход от архитектуры к исполнению.
Назначение архитектурного уровня
HLD используйте для объяснения назначения системы, состава подсистем, внешних взаимодействий и ключевых принципов. Покажите, почему выбрана архитектура и какие ограничения определили решение. Заказчику должно быть понятно, что изменится в его работе и от чего зависит результат. Не перегружайте этот уровень таблицами всех портов, но не скрывайте общие точки отказа и обязательные внешние сервисы. Ссылка на детальный документ допустима, если он действительно существует и раскрывает вопрос. Архитектурная схема без требований и оснований остаётся рисунком, а не согласованным техническим решением.
Что должно появиться в детализации
LLD раскрывает выбранную архитектуру до параметров реализации: адресного плана, соединений, размещения компонентов, настроек и зависимостей. Для каждого значимого решения верхнего уровня покажите, где оно реализовано. Если HLD требует разделения доступа, LLD должен объяснять, какие роли, сегменты и правила обеспечивают это разделение. Не считайте достаточным повторить общую фразу в другом документе. Детализация должна отвечать на вопросы инженера, который будет настраивать решение. Неопределённые параметры оформляйте как открытые вопросы с владельцами, а не как готовые значения.
Рабочий комплект доводит решение до места
РД или иной согласованный рабочий комплект показывает исполнителю конкретные места установки, маркировку и монтажные действия. Его границу с LLD определите заранее, чтобы таблицы не дублировались без контроля. Один источник адресов и обозначений предпочтительнее нескольких независимо редактируемых копий. Для каждого оборудования сохраняйте одинаковый идентификатор в архитектуре, настройках, спецификации и схемах. После изменения модели проверьте принадлежности и места подключения. Если проект не включает строительные работы, не приписывайте обозначению РД требования строительной документации без проверки применимости.
Связи проверяйте в обе стороны
Составьте таблицу: требование, решение HLD, реализация LLD, рабочий документ и проверка. Затем просмотрите её обратно: каждое значимое соединение и компонент должны иметь назначение. Отсутствие основания может означать пропущенное требование или лишнее усложнение. Разберите это с архитектором, не удаляя строку механически. Проверяйте также согласованность терминов и границ ответственности. Детальная схема может технически работать, но противоречить согласованной модели обслуживания. Прослеживаемость нужна для понимания таких последствий, а не только для отметок о наличии ссылок между файлами.
Пример: резервирование межсетевого экрана
В учебном проекте HLD предусматривает продолжение работы при отказе одного межсетевого экрана. В LLD описаны два устройства, но оба питаются от одной линии и используют общий незащищённый путь соединения. Проверка связей выявляет, что наличие пары не подтверждает заявленный сценарий устойчивости. Команда уточняет границу требования, питание и подключение, затем меняет рабочие схемы и программу испытаний. Если заказчик принимает ограниченный сценарий, это отражают на верхнем уровне. Нельзя оставить широкое обещание в HLD и объяснять фактическое ограничение только мелким примечанием LLD.
Изменения могут начинаться снизу
На площадке можно обнаружить ограничение, которого не было в исходных данных. Поэтому изменение не всегда рождается на архитектурном уровне. Важно другое: оценить, какие уровни оно затрагивает, получить решение и привести документы к согласованному состоянию. Для замены точки подключения может хватить детализации, а для смены схемы резервирования понадобится пересмотр HLD. Сохраните причину и перечень изменённых материалов. Перед выпуском проверьте не только схемы, но и эксплуатационные инструкции: новое решение должно оставаться понятным тем, кто будет поддерживать его после сдачи.
Проверка перед завершением
- ✓Согласуйте границы уровней.
- ✓Сохраняйте единые идентификаторы.
- ✓Проверяйте реализацию архитектурных обещаний.
Частые вопросы
Нужны ли три отдельных файла всегда?+
Можно ли менять LLD после обследования площадки?+
Продукт · Цены · Все материалы