20.02.2023 06.08.2026

High-Level Design

Общее

High-Level Design (HLD) - это этап проектирования программного обеспечения, на котором определяется общая архитектура системы: её крупные компоненты, их взаимодействие и потоки данных, без деталей внутренней реализации. HLD выполняется после сбора требований и до Low-Level Design (LLD).

Главный признак HLD - уровень абстракции. На этом уровне система рассматривается как совокупность «чёрных ящиков»: важно что делает каждый компонент и как они связаны, но не как компонент устроен внутри. Внутреннее устройство - задача LLD. Эта граница - ключевая: именно она позволяет менять реализацию компонента, не ломая архитектуру в целом.

HLD решает несколько задач:

  • фиксирует структурное разбиение системы и границы ответственности компонентов;
  • определяет протоколы и контракты взаимодействия (синхронные/асинхронные, форматы данных);
  • распределяет нефункциональные требования (NFR - производительность, надёжность, безопасность) по компонентам;
  • служит основой для оценки рисков, трудозатрат и для ADR - фиксации принятых архитектурных решений;
  • даёт всем участникам проекта (разработчикам, заказчику, operations) общее понимание системы.

Хорошо сделанный HLD абстрагирован от конкретных технологий настолько, насколько это разумно: он не должен жёстко привязываться к конкретной версии фреймворка или СУБД, но вполне может фиксировать класс решений (реляционная БД, брокер сообщений, кеш in-memory).

Принципы

Основные принципы, на которые опирается HLD:

  • Выбор архитектурного стиля - фундаментальное решение, определяющее облик системы: слоистая (layered), клиент-сервер, микросервисы, event-driven, hexagonal (ports & adapters), CQRS и др. Архитектурные стили описывают организацию системы в целом - в отличие от паттернов проектирования GoF, которые относятся к уровню LLD.

  • Разделение на слои (layering) - компоненты группируются в уровни (например, presentation → application → domain → infrastructure), которые взаимодействуются только с соседним или более низким уровнем. Это упрощает проектирование и обеспечивает масштабируемость.

  • Определение интерфейсов (contracts) - описание того, как компоненты взаимодействуют друг с другом. Интерфейсы на уровне HLD - это контракты API (REST/gRPC), форматы событий, схемы сообщений. Они позволяют изолировать компоненты и развивать их независимо.

  • Чёткие границы ответственности (bounded contexts) - каждый компонент имеет свою зону ответственности и не «лезет» в чужую. Это прямая связь с DDD: стратегическое DDD (карта контекстов) отражается именно на уровне HLD.

  • Учёт требований качества (NFR) - производительность, надёжность, безопасность, наблюдаемость (observability) закладываются на уровне HLD. Каждый компонент должен проектироваться с учётом соответствующих NFR; переносить их на этап кодирования - поздно и дорого.

Что входит в HLD

Артефакты HLD - это набор диаграмм и текстовых спецификаций. Состав варьируется, но ядро устойчиво:

Артефакт Что описывает Типовой инструмент
System Context систему во внешнем окружении: внешние пользователи и интегрируемые системы C4 Level 1 (Context), UML use case
Component View разбиение системы на крупные компоненты и связи между ними C4 Level 2 (Container), UML component diagram
Deployment View как компоненты разворачиваются на инфраструктуре (серверы, контейнеры, регионы) UML deployment diagram, C4 Level 4 (Deployment)
Концептуальная модель данных ключевые сущности предметной области и их связи (без атрибутов и типов) UML class diagram (концептуальный уровень)
Контракты интерфейсов публичные API и форматы обмена данными между компонентами OpenAPI (REST), .proto (gRPC), AsyncAPI/схемы событий
Распределение NFR какие требования качества и к каким компонентам/связям относятся таблица, атрибуты на диаграммах
Сквозные сценарии обработка критичных потоков (аутентификация, платёж, отказ узла) UML sequence/activity, 4+1 view

Важно: ER-диаграмма с атрибутами и типами, диаграмма классов с методами, схема таблиц БД - это артефакты LLD, не HLD. На уровне HLD достаточно концептуальной модели: «есть сущности Заказ, Клиент, Товар, и они так связаны».

Процесс

Процесс работы над HLD обычно включает следующие этапы:

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

  2. Выбор архитектурного стиля: решение о том, какой стиль (микросервисы, слоистый монолит, event-driven и т.д.) лучше отвечает требованиям и ограничениям. Каждое такое решение целесообразно фиксировать как ADR.

  3. Проектирование структуры системы (component view): выделение основных компонентов, их ответственности и границ. Результат - диаграмма компонентов (или C4 Container), на которой видны «чёрные ящики» и связи между ними.

  4. Проектирование развёртывания (deployment view): отображение компонентов на инфраструктуру - где физически/логически они исполняются, как связаны сети, где проходят границы доверия.

  5. Определение интерфейсов и протоколов: фиксация контрактов взаимодействия (синхронные API, асинхронные события), форматов данных и схем. Это «клей», который позволяет компонентам общаться.

  6. Распределение NFR и анализ сквозных сцениев: проверка, что требования качества достижимы в предложенной структуре; проработка критичных потоков (sequence diagrams) и сценариев отказа.

  7. Документирование: оформление HLD в виде спецификации с диаграммами. Документация может жить как в wiki, так и в репозитории рядом с кодом (docs-as-code).

  8. Обзор и проверка: ревью архитектуры (peer-архитекторы, заказчик, operations), верификация соответствия требованиям и выявление рисков до перехода к LLD.

HLD в современных методологиях

В классическом (водопадном) подходе HLD - это тяжёлый документ, полностью написанный до начала разработки. В современных методологиях отношение к HLD изменилось, но сам уровень не исчез:

  • Agile / Scrum. HLD не пишется «весь сразу», а появляется «достаточно для старта» (just-enough design) и уточняется в ходе работы. Для крупных или рискованных частей системы выделяют архитектурные спайки (architectural spikes) - отдельные итерации на исследование и HLD. Принцип: проектирование впереди, но не далеко.

  • Критика BDUF (Big Design Up Front). Попытка продумать HLD до последней детали заранее - антипаттерн: требования меняются, а переписывать тяжёлый документ дорого. Современный подход - итеративное уточнение HLD и поддержание его актуальным (living documentation).

  • 4+1 View Model (Крухтен). Классический каркас Филиппа Крухтена (1995), который структурирует HLD через четыре представления - Logical, Process, Development, Physical - плюс сквозные сценарии (Scenarios). Даёт чек-лист: «все ли аспекты архитектуры описаны».

  • Модель C4 (Simon Brown). Популярный сегодня способ визуализации архитектуры на нескольких уровнях зума: Context → Container → Component → Code. Уровни C4 Context и Container - это по сути HLD; Component и Code - LLD. C4 пришёл на смену тяжёлому UML и проще в поддержании.

  • arc42. Шаблон архитектурного документа из 12 разделов (от контекста и решений до рисков и глоссария). arc42 хорошо ложится и на HLD, и на полноценный архитектурный документ; сочетается с C4 и docs-as-code.

  • Docs-as-code и ADR. HLD хранится рядом с кодом в Markdown/AsciiDoc, версонируется в git и ревьюится через PR. Отдельные архитектурные решения выносятся в ADR, а HLD ссылается на них, не дублируя обоснование.

Плюсы

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

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

Обеспечивает масштабируемость и гибкость: грамотное разбиение и границы ответственности позволяют менять или заменять компоненты локально, не ломая систему целиком.

Улучшает коммуникацию: единое понимание системы у разработчиков, аналитиков, заказчика и operations - снижает количество переделок из-за разночтений.

Даёт основу для LLD и оценки: на HLD можно дать трудозатраты и план разработки; LLD становится механическим продолжением, а не новым проектированием.

Минусы

Может занимать много времени: детальная проработка HLD «до гвоздя» для сложной системы - это риск скатиться в BDUF и затянуть старт разработки.

Ограниченная точность на раннем этапе: на момент HLD известны не все нюансы; часть решений всё равно пересматривается в LLD или при кодировании. HLD не может и не должен быть исчерпывающим.

Риск «бетонирования» архитектуры: если HLD воспринимать как неприкосновенный документ, любые изменения потребуют формальной процедуры - и система теряет гибкость.

Не подходит для быстрых экспериментов: для прототипа, проверки концепции (PoC) или стартапа в режиме поиска продукта полноценный HLD избыточен - там достаточно наброска и кода.

Когда применять

При разработке сложных распределённых систем: микросервисные ландшафты, системы с множеством интеграций, highload - здесь цена архитектурной ошибки максимальна.

При работе в нескольких командах: HLD становится общим контрактом, позволяющим командам не наступать друг другу на ноги.

В проектах с высокими требованиями к надёжности и безопасности: финтех, медицина, критическая инфраструктура - где отказ или утечка недопустимы и HLD проверяется регулятором/аудитом.

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

Когда достаточно наброска: для прототипа, PoC или небольшой утилиты формальный HLD не нужен - хватит схемы на доске и краткого README.

Кто пишет и ревьюит

Роль Ответственность
Архитектор / Solution Architect Автор HLD: отвечает за структуру, выбор стиля, контракты, распределение NFR
Tech Lead команды Соавтор: детализирует компоненты своей команды, валидирует реализуемость
Peer-архитекторы Ревью: проверяют согласованность с другими системами и стандартами
Operations / DevOps / SecOps Ревью: Deployment View, NFR по доступности/безопасности, наблюдаемость
Заказчик / Product Owner Приёмка: подтверждает, что HLD отвечает бизнес-требованиям

Критерии готовности (DoD)

HLD считается готовым к передаче в LLD, когда:

  • описаны все компоненты и их ответственность, нет «белых пятен»;
  • зафиксированы контракты взаимодействия (API, события, схемы);
  • выполнен Deployment View и показано, как система разворачивается;
  • NFR распределены по компонентам и проверены на достижимость;
  • проработаны критичные сквозные сценарии и сценарии отказов;
  • ключевые решения зафиксированы в ADR;
  • HLD прошёл ревью у peer-архитекторов, operations и заказчика;
  • документ актуален и доступен команде (а не «лежит в столе»).

Пример

Рассмотрим HLD для онлайн-магазина на уровне компонентов (C4 Container). Без деталей реализации:

  • Web-фронтенд (SPA) - каталог, корзина, оформление заказа. Взаимодействует с Backend API по REST.
  • Backend API (модуль приложения) - бизнес-логика каталога и заказов. Синхронно вызывает Платёжный шлюз, читает/пишет БД Заказов, публикует события в Брокер сообщений.
  • База данных Заказов (реляционная СУБД) - постоянное хранилище заказов, клиентов, статусов.
  • Платёжный шлюз (внешняя система) - приём оплаты; Backend API вызывает его по REST.
  • Брокер сообщений - асинхронная шина; Backend публикует событие OrderPlaced, его читают Сервис уведомлений и Сервис аналитики.
  • Сервис уведомлений - подписан на OrderPlaced, шлит email/SMS клиенту.
  • Сервис аналитики - подписан на события заказов, обновляет витрины данных.
  • Кеш (in-memory, Redis) - кеширование каталога для снижения нагрузки на БД.

Deployment View покажет: фронтенд - в CDN, Backend API и сервисы - в контейнерном оркестраторе в двух зонах доступности, БД - managed-кластер с репликацией, Брокер - отдельный managed-сервис. NFR: Backend API - p99 ≤ 300 мс на чтение каталога, БД - RPO ≤ 1 мин, Сервис уведомлений - eventual consistency (письмо приходит в течение минуты).

Этот уровень описания - HLD. Как именно устроен OrderService внутри (классы, таблицы, алгоритмы) - уже LLD.

Сравнение HLD и LLD

Ось HLD LLD
Уровень Общая архитектура, «чёрные ящики» Детальная реализация, «белый ящик»
Главный вопрос Из каких частей состоит система и как они связаны Как устроена каждая часть внутри
Артефакты Component/Deployment/Context, концептуальная модель данных, контракты API, распределение NFR Диаграммы классов/последовательностей, ER-схема БД, алгоритмы, обработка ошибок, тест-план
Степень детализации Что делает компонент, без внутренней реализации Как именно: классы, методы, таблицы, алгоритмы
Кто пишет Архитектор / Solution Architect Tech Lead / ведущий разработчик компонента
Кто ревьюит Peer-архитекторы, operations, заказчик Команда, архитектор (границы и контракты)
Отношение к технологиям Класс решений (реляционная БД, брокер), но не версия Конкретные технологии, библиотеки, версии
Когда выполняется После требований, до LLD После HLD, до/параллельно с кодированием

См. также