Требования к ПО

Архитектурные требования и ограничения

📚 25 вопросовПройти тест →
Лекция

Архитектурные требования и ограничения

Требования к ПО

Архитектурные требования и ограничения

Введение: правила строительства 🏗️

Можно придумать красивый дом, но если грунт слабый — нужен другой фундамент.
Архитектурные требования и ограничения задают рамки, в которых можно строить систему.
Эта лекция про то, как фиксировать архитектурные решения и ограничения, чтобы проект не развалился на этапе реализации.
💡 Совет: архитектура — это не «вкус», а набор ограничений и компромиссов.
✅ Вывод: чёткие архитектурные требования защищают систему от дорогих переделок.

Проблема: «сделали, но не проходит по инфраструктуре» ❌

Без архитектурных требований:
  • команда выбирает разные технологии;
  • интеграции ломаются из‑за несовместимости;
  • инфраструктура не выдерживает нагрузку.
С требованиями:
  • все понимают рамки;
  • решения согласованы заранее;
  • меньше технического долга.
✅ Вывод: архитектурные ограничения — это страховка проекта.

Чем помогает и как работает

  • Помогает синхронизировать команды вокруг единой структуры системы и технологических рамок.
  • Помогает снизить технический долг за счёт ранней фиксации ограничений и границ интеграций.
  • Помогает заранее оценить масштабирование, безопасность и риски внедрения.
Как это работает:
  • Шаг 1: фиксируем архитектурный стиль и зоны ответственности.
  • Шаг 2: задаём ограничения по стеку, инфраструктуре и безопасности.
  • Шаг 3: добавляем требования к нагрузке и интеграционным границам.
  • Шаг 4: документируем ключевые решения в ADR.
  • Шаг 5: определяем критерии приёмки и проверку архитектуры.
✅ Вывод: архитектурные требования превращают «делаем как удобнее» в согласованный инженерный контракт.

Ключевые термины (простыми словами)

  • Architecture Requirement (архитектурное требование) — требование к структуре и ключевым решениям системы.
  • Constraint (ограничение) — жёстное условие, которое нельзя нарушать.
  • Tech Stack (стек технологий) — набор обязательных технологий.
  • Deployment Model (модель развёртывания) — где и как работает система.
  • Integration Boundary (граница интеграции) — как и с кем система взаимодействует.
  • Quality Attributes (качества) — скорость, масштабируемость, надёжность.
  • ADR (Architecture Decision Record) — документ решения с причиной.
✅ Вывод: эти термины помогают фиксировать архитектуру как договор.

Самое важное (must-know)

  • Архитектурное требование описывает структуру и качество системы, ограничение задаёт жёсткую рамку.
  • Стек, облако и интеграционные правила должны быть зафиксированы до активной разработки.
  • Нагрузка и масштабирование обязаны иметь численные параметры (rps, p95, пределы роста).
  • Прямые интеграции в БД между системами — архитектурный анти-паттерн.
  • Ключевые решения фиксируются в ADR вместе с причинами и trade-off.
✅ Вывод: без этих пунктов архитектура становится неуправляемой и конфликтной.

1. Архитектурные требования

Назначение: описать ключевые решения структуры системы.
Простыми словами: архитектурные требования задают каркас системы: как она разделена, кто за что отвечает и как части взаимодействуют.
Аналогия: тип дома — дом, многоэтажка или модульный.
Пример:
Система должна быть разделена на сервисы: каталог, оплата, профиль.
🔎 Как это происходит на практике:
  1. Техлид выделяет ключевые домены и сервисы.
  2. Команда фиксирует границы ответственности каждого сервиса.
  3. Архитектура сверяется с целевой нагрузкой и roadmap.
  4. Согласованная схема фиксируется в документе.
Характеристики:
  • ✅ определяют структуру;
  • ✅ влияют на масштабирование;
  • ✅ задают границы ответственности.
Когда использовать: при старте проекта или крупном рефакторинге.
✅ Вывод: архитектура должна быть явно зафиксирована.

2. Архитектурные ограничения

Назначение: задать жёсткие рамки.
Простыми словами: архитектурные ограничения — это обязательные правила, которые нельзя менять локально без отдельного решения.
Аналогия: «строим только из кирпича».
Пример:
База данных: только PostgreSQL.Развёртывание: только в AWS.
🔎 Как это происходит на практике:
  1. Собираются корпоративные и регуляторные ограничения.
  2. Определяются обязательные технологии и платформа.
  3. Проверяется влияние ограничений на сроки и бюджет.
  4. Ограничения утверждаются и становятся частью контракта.
Характеристики:
  • ✅ не обсуждаются без согласования;
  • ✅ влияют на стоимость и сроки;
  • ✅ ограничивают выбор решений.
Когда использовать: при наличии корпоративных стандартов или юридических требований.
✅ Вывод: ограничения — это обязательные правила игры.

3. Нагрузка и масштабируемость

Назначение: учесть рост и пики.
Простыми словами: нагрузка и масштабирование определяют, сможет ли архитектура выдержать реальный рост продукта.
Аналогия: дорога должна выдерживать пробки.
Пример:
Пик: 1000 rps, p95 <= 300 мс.
🔎 Как это происходит на практике:
  1. Аналитик фиксирует профиль нагрузки и пик.
  2. Задаются целевые метрики производительности (например, p95).
  3. Архитектура проверяется нагрузочными тестами.
  4. При отклонениях пересматриваются узкие места и масштабирование.
Характеристики:
  • ✅ задают требования к инфраструктуре;
  • ✅ влияют на архитектурный стиль;
  • ✅ помогают планировать ресурсы.
Когда использовать: для публичных сервисов и роста.
✅ Вывод: без требований к нагрузке архитектура «слепая».

4. Интеграционные границы

Назначение: определить, как системы общаются.
Простыми словами: границы интеграции защищают систему от хаоса и позволяют менять внутреннюю реализацию без ломки внешних связей.
Аналогия: ворота и пропускной пункт.
Пример:
Интеграция с CRM только через REST API, без прямого доступа к БД.
🔎 Как это происходит на практике:
  1. Определяются разрешённые интерфейсы интеграций.
  2. Запрещаются обходные пути (например, прямой доступ в БД).
  3. Документируются контракты и версии API.
  4. На ревью проверяется соблюдение границ всеми командами.
Характеристики:
  • ✅ фиксируют интерфейсы;
  • ✅ защищают систему от обходных решений;
  • ✅ облегчают сопровождение.
Когда использовать: при работе с внешними системами.
✅ Вывод: границы интеграции защищают архитектуру.

5. Инфраструктурные требования

Назначение: зафиксировать среду работы системы.
Простыми словами: инфраструктурные требования фиксируют среду исполнения, чтобы поведение системы было предсказуемым на всех этапах.
Аналогия: «строим дом только на этом участке».
Пример:
ОС: LinuxКонтейнеры: DockerCI/CD: GitHub Actions
🔎 Как это происходит на практике:
  1. Команда выбирает стандарт ОС и контейнеризации.
  2. Фиксируется CI/CD и правила деплоя.
  3. Проверяется совместимость сред разработки и прода.
  4. Стандарты включаются в Definition of Done.
Характеристики:
  • ✅ единая среда;
  • ✅ снижает риск несовместимости;
  • ✅ упрощает поддержку.
Когда использовать: при корпоративных стандартах.
✅ Вывод: инфраструктура — часть требований.

6. Безопасность как архитектурное ограничение

Назначение: защитить данные и доступ.
Простыми словами: безопасность на уровне архитектуры задаёт обязательные технические меры, а не пожелания «по возможности».
Аналогия: охрана на объекте.
Пример:
Все сервисы общаются только по mTLS.Данные PII шифруются в покое.
🔎 Как это происходит на практике:
  1. Определяются критичные данные и каналы обмена.
  2. Фиксируются требования к шифрованию и транспорту.
  3. Проверяется соответствие требованиям compliance.
  4. Меры безопасности включаются в архитектурные ограничения.
Характеристики:
  • ✅ жёсткие требования;
  • ✅ влияет на дизайн системы;
  • ✅ обязательны для compliance.
Когда использовать: при работе с персональными данными.
✅ Вывод: безопасность — это архитектура, а не опция.

7. ADR: фиксация решений

Назначение: объяснить, почему архитектура такая.
Простыми словами: ADR нужен, чтобы сохранить не только выбор решения, но и причину выбора с его компромиссами.
Аналогия: записка «почему выбрали этот маршрут».
Пример:
ADR‑01: выбран PostgreSQL из‑за транзакций и зрелой экосистемы.
🔎 Как это происходит на практике:
  1. Для решения описывается контекст и доступные варианты.
  2. Фиксируется выбранный вариант и аргументация.
  3. Указываются последствия и ограничения решения.
  4. ADR связывается с задачами реализации и проверкой.
Характеристики:
  • ✅ сохраняет контекст решений;
  • ✅ помогает новым участникам;
  • ✅ снижает риск повторных споров.
Когда использовать: при важных архитектурных решениях.
✅ Вывод: ADR делает архитектуру прозрачной.

Сравнение: требование vs ограничение

ПараметрТребованиеОграничение
Гибкостьможно обсуждатьжёсткое
Источникбизнес/техполитика/регламент
Пример«масштабируемость»«только AWS»

Часто спрашивают на собеседованиях

  • Чем архитектурное требование отличается от ограничения? требование можно выбирать, ограничение — жёсткое.
  • Зачем фиксировать стек технологий? чтобы избежать несовместимости.
  • Что такое ADR? запись архитектурного решения с причиной.
  • Почему важны интеграционные границы? защита от хаоса и прямых доступов.
  • Как нагрузка влияет на архитектуру? определяет масштабирование.
✅ Вывод: это ключевые вопросы по архитектурным требованиям.

Типичные ошибки

Ошибка 1: стек не зафиксирован

❌ разные команды используют разные БД
✅ единый стек

Ошибка 2: нет ограничений

❌ инфраструктура не выдерживает
✅ жёсткие рамки

Ошибка 3: интеграции напрямую в БД

❌ ломают архитектуру
✅ только через API

Ошибка 4: нет требований к нагрузке

❌ система падает в пик
✅ описан пик и метрики

Ошибка 5: решения не задокументированы

❌ спорим заново
✅ ADR с причинами

Best Practices

  • Фиксируйте архитектурный стиль и ключевые решения.
  • Описывайте жёсткие ограничения заранее.
  • Указывайте требования к нагрузке и масштабированию.
  • Запрещайте прямой доступ к чужим БД (только через API).
  • Документируйте решения в ADR.

Заключение

Ключевые мысли

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

Проверьте знания

Закрепите материал — пройдите тест по теме «Архитектурные требования и ограничения»

Пройти тест →