Перейти к основному содержимому

Проектирование и архитектура — итоги

НЕ ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Архитектору Аналитику
Теория данных (раздел 3)

Модель и масштаб — Основы БД, опорные темы, проектирование БД, пакетная работа. Карта — о разделе.

Пройдя раздел, вы должны уметь объяснить, почему система устроена так, а не только перечислить паттерны. Ниже — сжатая карта решений из реальных проектов.

FAQ — Часто задаваемые вопросы​

Типичные архитектурные ошибки и давление "сделать как в Big Tech". Здесь — практика и ссылки на раздел; определения паттернов и SOLID для зачёта — в чек-листе.

Вопрос. Тимлид предлагает "сразу микросервисы" — команда из пяти человек, один релиз в месяц.

Ответ. Часто достаточно модульного монолита с чёткими границами пакетов; микросервисы окупаются при независимых релизах и зрелом DevOps. Подробнее здесь — модульный монолит, микросервисы, декомпозиция.

Вопрос. Сервисов десять, но любое изменение требует согласовать пять репозиториев — это норма?

Ответ. Похоже на распределённый монолит: общая БД, синхронные цепочки, жёсткие контракты. Упростите границы или верните связность в один deployable. Подробнее здесь — микросервисы, итоги и чек-лист.

Вопрос. NFR в ТЗ записаны как "система должна быть быстрой и надёжной".

Ответ. Переведите в цифры: p95 latency, RPS, доступность %, RTO/RPO, объём данных. Без этого нельзя выбрать кэш, реплики и очереди. Подробнее здесь — NFR, SLA и доступность.

Вопрос. ADR пишут, но никто не читает — спорят заново через полгода.

Ответ. ADR должен содержать контекст, решение, последствия и отвергнутые варианты; храните рядом с кодом, ссылайтесь в PR. Короткий живой документ лучше папки "архитектура". Подробнее здесь — роль архитектора, trade-off.

Вопрос. Два сервиса читают и пишут в одну таблицу заказов.

Ответ. Нарушена изоляция данных: меняйте владельца таблицы, остальным — API или события. Иначе миграции и блокировки станут узлом. Подробнее здесь — микросервисы, доменная модель.

Вопрос. Цепочка из пяти синхронных REST-вызовов — страница грузится 8 секунд.

Ответ. Сократите цепочку (агрегация, BFF), вынесите некритичное в асинхрон, кэшируйте чтение. Синхронная сеть умножает задержки. Подробнее здесь — API, интеграции.

Вопрос. События приходят дважды — баланс списался два раза.

Ответ. Нужны идемпотентность и ключ операции; at-least-once доставка без этого ломает деньги. Подробнее здесь — событийная архитектура, устойчивость.

Вопрос. "Возьмём Mongo, потому что CAP — всегда AP".

Ответ. CAP — про поведение при разделении сети; в обычной работе смотрите PACELC и конкретные гарантии чтения/записи. Подробнее здесь — распределённые системы, выбор хранилища.

Вопрос. Saga запустили, а компенсирующие шаги не проектировали.

Ответ. Распределённая транзакция без компенсации оставляет "висящие" заказы и платежи. Пройдите happy path и откаты. Подробнее здесь — саги, микросервисы.

Вопрос. Легаси "нельзя трогать" — бизнес требует переписать всё за год.

Ответ. Чаще выигрывает Strangler: узкие потоки выводятся в новый контур по одному. Big bang рискует остановить бизнес. Подробнее здесь — Strangler Fig, декомпозиция.

Вопрос. На проекте внедряют DDD везде — сущностей больше, чем экранов.

Ответ. DDD уместен в сложном домене; иначе получите церемонию без выгоды. Начните с bounded context на карте, не с "Entity на каждую кнопку". Подробнее здесь — доменная модель, Event Storming.

Вопрос. Вся логика в сервисном слое, сущности — только геттеры.

Ответ. Это анемичная модель: инварианты размазаны, баги при изменении полей. Часть правил верните в агрегаты. Подробнее здесь — доменная модель, обзор паттернов.

Вопрос. Команда внедрила Factory + Builder + Strategy в один модуль "на будущее".

Ответ. Паттерн без конкретной боли усложняет чтение. Сначала дублирование или ветвления, потом приём. Подробнее здесь — паттерны GoF, обзор.

Вопрос. C4 нарисовали до уровня каждого класса — диаграмма не обновляется.

Ответ. Держите C4 на system/context и container; детали — в коде и ADR. Устаревшая диаграмма хуже отсутствующей. Подробнее здесь — основы проектирования, роль архитектора.

Вопрос. Поменяли поле в API — мобильные клиенты массово падают.

Ответ. Нужна версия контракта, обратная совместимость или параллельный v2; ломающие изменения — по расписанию с метриками adoption. Подробнее здесь — API, уровни API Ричардсона.

Вопрос. Webhook от банка иногда приходит повторно — заказ дублируется.

Ответ. Обработчик должен быть идемпотентным (id платежа, уникальный индекс). Подробнее здесь — API, интеграции.

Вопрос. После деплоя кэш показывает старые цены сутками.

Ответ. Продумайте инвалидацию: TTL, событие изменения, версия ключа. "Поставили Redis" без политики — частый источник инцидентов. Подробнее здесь — практика масштабирования, NFR.

Вопрос. Read replica есть, пользователь не видит только что созданный заказ.

Ответ. Это лаг репликации: чтение после записи направляйте на primary или используйте read-your-writes. Подробнее здесь — масштабирование, 12 концепций архитектуры распределённых систем — концепции.

Вопрос. Горизонтально масштабировали API, сессии "вылетают" при переключении на другой pod.

Ответ. Сессии в памяти pod не переносятся: sticky sessions или внешнее хранилище (Redis), лучше stateless JWT с оговорками безопасности. Подробнее здесь — практика, балансировка.

Вопрос. SLA "99.9 %" в договоре, а RTO/RPO никто не считал.

Ответ. Свяжите SLA с резервным копированием, DR и архитектурой (multi-AZ, реплики). Иначе цифра в PDF не спасёт при падении ЦОД. Подробнее здесь — SLA, устойчивость.

Вопрос. Меня зовут "архитектором", но задачи — только код review.

Ответ. Уточните роль: solution vs enterprise, владение NFR, ADR, границы сервисов. Без полномочий на решения вы consultant, не architect. Подробнее здесь — роль архитектора, практика.

Вопрос. Conway: две команды, один общий модуль в монолите — постоянные merge-конфликты.

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

Вопрос. POC на хакатоне понравился — через месяц его тащат в прод.

Ответ. POC проверяет гипотезу, не эксплуатацию: заложите переписывание, безопасность, наблюдаемость, нагрузку. Подробнее здесь — практика, trade-off.

Вопрос. В проде инцидент — в логах нет trace id между сервисами.

Ответ. Наблюдаемость (логи, метрики, distributed tracing) закладывают в дизайн, не "после аварии". Подробнее здесь — микросервисы, мониторинг.

Вопрос. Threat modeling никто не делал — утечка через открытый S3.

Ответ. Пройдите STRIDE/модель угроз на критичных потоках (деньги, ПДн, админка). Подробнее здесь — threat modeling, ИБ.

Вопрос. Два bounded context в одном репозитории — споры "чей пакет".

Ответ. Зафиксируйте границы и публичные API между контекстами; общие таблицы — антипаттерн. Подробнее здесь — доменная модель, Event Storming.

Вопрос. Техдолг копится — фичи "горят", рефакторинг откладывают каждый спринт.

Ответ. Свяжите долг с риском и стоимостью задержки; выделяйте квоту, метрики дефектов и время доставки. ADR фиксирует осознанный компромисс. Подробнее здесь — trade-off, практика.

Вопрос. Как понять, что архитектурная гипотеза сработала после релиза?

Ответ. Заранее задайте метрики (latency, error rate, стоимость, time-to-recover) и период наблюдения; иначе спорят вкусом. Подробнее здесь — роль архитектора, system design — карта.

Вопрос. Монолит vs микросервисы — как аргументировать на review без холивара?

Ответ. Таблица по NFR, командам, частоте релизов, зрелости CI/CD и стоимости владения; один "правильный" ответ для всех продуктов нет. Подробнее здесь — Стратегии декомпозиции монолитных систем, Паттерны микросервисной архитектуры, чек-лист.

Вопрос. Новичок: с чего начать раздел, если паттерны GoF путаются?

Ответ. Сначала основы и стили, затем домен и один стиль деплоя; GoF — точечно под задачу. Подробнее здесь — о разделе, карта system design.

Вопрос. Что такое микросервисная архитектура простыми словами?

Ответ. Система из нескольких независимо развёртываемых сервисов со своими данными и API; цена — сеть, согласованность, observability. Подробнее здесь — микросервисы, декомпозиция.

Вопрос. Монолит или микросервисы — что выбрать для стартапа?

Ответ. Часто старт с монолита или модульного монолита; резать на сервисы при доказанной необходимости (релизы, нагрузка, команды). Подробнее здесь — модульный монолит, Стратегии декомпозиции монолитных систем.

Вопрос. SOLID принципы — кратко для собеседования?

Ответ. S — одна ответственность класса; O — расширение без ломки; L — подтипы заменяемы; I — узкие интерфейсы; D — зависимость от абстракций. Подробнее здесь — основы проектирования, паттерны и SOLID.

Вопрос. Паттерны проектирования GoF — сколько их и зачем?

Ответ. Классические 23 паттерна (порождающие, структурные, поведенческие) для повторяющихся задач в коде. Учите по проблеме, не списком. Подробнее здесь — паттерны — о разделе.

Вопрос. Чистая архитектура (Clean Architecture) — что это?

Ответ. Слои: домен в центре, use cases, адаптеры UI/БД; зависимости направлены внутрь. Упрощает тесты и смену фреймворка. Подробнее здесь — чистая архитектура — теория, практика ASP.NET.

Вопрос. CQRS — что это и когда применять?

Ответ. Разделение моделей чтения и записи; уместно при разной нагрузке на read/write и сложных отчётах. Подробнее здесь — микросервисы и CQRS, стили архитектуры.

Вопрос. Event Sourcing — зачем хранить события вместо состояния?

Ответ. Полная история изменений, аудит, восстановление состояния replay; сложнее эксплуатация. Подробнее здесь — событийная архитектура, микросервисы.

Вопрос. Saga pattern в микросервисах — как работает?

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

Вопрос. CAP теорема — объяснение для начинающих?

Ответ. При разделении сети выбирают между согласованностью (C) и доступностью (A); P — устойчивость к partition. В нормальной работе смотрите PACELC. Подробнее здесь — распределённые системы.

Вопрос. Горизонтальное и вертикальное масштабирование — в чём разница?

Ответ. Вертикальное — мощнее сервер; горизонтальное — больше узлов за балансировщиком. Подробнее здесь — практика масштабирования, 12 концепций.

Вопрос. REST API best practices — что заложить в дизайн?

Ответ. Ресурсы, идемпотентность PUT/DELETE, версионирование, коды ошибок, пагинация, OpenAPI. Подробнее здесь — проектирование API, уровни Ричардсона.

Вопрос. System design interview — с чего готовиться?

Ответ. NFR в цифрах, оценка нагрузки, схема компонентов, данные, кэш, очереди, отказоустойчивость, trade-off. Подробнее здесь — карта system design, 12 концепций, практика.

Вопрос. C4 model — какие уровни диаграмм?

Ответ. Context → Container → Component → Code (последний редко вручную). Для команды обычно хватает 1–2. Подробнее — основы диаграмм и моделирования, основы проектирования, роль архитектора.

Вопрос. DDD (Domain-Driven Design) — что такое bounded context?

Ответ. Граница единого языка и модели домена; разные контексты — разные термины "клиент", "заказ". Подробнее здесь — доменная модель, Event Storming.

Вопрос. Strangler Fig pattern — как мигрировать с легаси?

Ответ. Новый функционал идёт в обход старого, трафик постепенно переключают, старое "засыхает". Подробнее здесь — Strangler Fig, декомпозиция.

Вопрос. Модульный монолит — что это?

Ответ. Один deployable с чёткими модулями внутри (границы пакетов, API между модулями) — компромисс до микросервисов. Подробнее здесь — модульный монолит.

Вопрос. ADR (Architecture Decision Record) — шаблон?

Ответ. Контекст, решение, статус, последствия, отвергнутые варианты — короткий markdown в репозитории. Подробнее здесь — роль архитектора, trade-off.

Вопрос. High availability 99.9 % — сколько простоя в год?

Ответ. 99.9 % ("три девятки") — порядка 8,76 часов простоя в год; каждая девятка уменьшает допуск. Подробнее здесь — SLA и доступность.

Вопрос. Load balancer — зачем нужен перед серверами?

Ответ. Распределяет трафик, health checks, SSL termination; алгоритмы round-robin, least connections и др. Подробнее здесь — балансировка, масштабирование.

Вопрос. Идемпотентность API — как реализовать?

Ответ. Ключ Idempotency-Key или уникальный id операции в БД; повтор запроса не дублирует эффект. Подробнее здесь — API, интеграции.

Вопрос. BFF (Backend for Frontend) — когда нужен?

Ответ. Когда у мобильного и веб-клиента разные агрегации данных и меньше чаттеринга к микросервисам. Подробнее здесь — API, микросервисы.

Вопрос. Event-driven architecture (EDA) — плюсы и минусы?

Ответ. Плюсы — слабая связность, масштаб; минусы — отладка, порядок, идемпотентность. Подробнее здесь — событийная архитектура.

Вопрос. Software architect — чем отличается от tech lead?

Ответ. Архитектор фокус на границах системы, NFR, ADR; tech lead — на доставке команды и коде. Роли пересекаются. Подробнее здесь — роль архитектора.

Вопрос. Kubernetes обязателен для микросервисов?

Ответ. Нет: микросервисы — про границы и деплой; оркестрация может быть проще (VM, PaaS) пока не выросла сложность. Подробнее здесь — микросервисы, DevOps.

Вопрос. Anti-corruption layer (ACL) — что это в DDD?

Ответ. Слой перевода между вашей моделью и легаси/API чужой системы, чтобы чужие термины не проникли в домен. Подробнее здесь — доменная модель, декомпозиция.

Главная мысль​

Проектирование — структура до и во время разработки. Архитектура — то, что менять больно всего (развёртывание, границы подсистем, данные, интеграции). Дизайн (классы, GoF) живёт внутри выбранного каркаса.

Четыре уровня​

УровеньВопросПример
ФункциональныйЧто делает система?User stories
ДоменныйКакие правила?Bounded context, агрегаты
ПрикладнойИз чего собрано?C4 Container
ТехнологическийГде крутится?Deployment, SLA

Стили — когда уместны​

  • Монолит / модульный монолит — мало команд, сильная связность домена, простые транзакции.
  • Микросервисы — независимые релизы, разная нагрузка, зрелый DevOps; цена — сеть и согласованность.
  • События — слабая связность; сложность — идемпотентность и отладка.
  • Легаси — Strangler, декомпозиция, без "переписать за год".
Правило

Начинайте с самой простой архитектуры, которая измеримо закрывает NFR. Усложняйте по фактам нагрузки и организации.

Три частых ошибки​

  1. Микросервисы по умолчанию → модульный монолит, метрики, потом резка.
  2. Анемичная доменная модель → инварианты в агрегатах, доменная модель.
  3. Паттерны ради паттернов → сначала боль, потом приём; обзор.

Чек перед проектом​

  • NFR в цифрах?
  • Границы модулей/сервисов согласованы с командами?
  • Интеграции с контрактом и сценарием отказа?
  • ADR на спорные решения?
  • Метрики и трейсы в проде?

Полный список — Проектирование и архитектура — чек-лист (включая блок "архитектурное мышление").

Куда идти дальше​

Последнее обновление
Содержание