Архитектура и документация

Идентификация — заявление, кто вы (логин или id). Аутентификация — доказательство заявления (пароль, токен, биометрия). Авторизация — решение, что аутентифицированной личности разрешено делать. Порядок фиксирован — идентификация, аутентификация, авторизация действия.

Клиент-сервер делит ПО на клиента, запрашивающего услугу, и сервер, выполняющий её по сети. Трёхуровневое приложение разделяет уровень представления (UI), уровень прикладной логики и уровень данных, каждый из которых масштабируется независимо.

Слоистая архитектура складывает код в горизонтальные слои, у каждого одна работа: представление, бизнес-логика, доступ к данным и база. Слой вызывает только слой прямо под ним, поэтому зависимости идут в одну сторону, а слой тестируется отдельно.

Монолит — одно развёртываемое приложение, где все модули делят процесс и обычно одну базу — просто собирать, но трудно масштабировать по частям. Микросервисы разбивают систему на независимо развёртываемые сервисы, каждый владеет своими данными и общается по сети — гибко, ценой сложности распределённой системы.

Аналитик передаёт представления, фиксирующие, что строить: компонентную диаграмму (части и зоны ответственности), диаграммы последовательности (ход сценария), модель данных (сущности и связи) и контракты API. Каждое отвечает на свой вопрос.

RBAC (ролевая) выдаёт права через роли, назначенные пользователю. ABAC (атрибутивная) решает доступ по атрибутам пользователя, ресурса и контекста — гибче, но сложнее. Наименьшие привилегии дают только минимально необходимые права, сужая радиус поражения.

API Gateway — единая точка входа перед микросервисами: маршрутизация плюс сквозные заботы — аутентификация, ограничение частоты, агрегация, версионирование. Балансировщик лишь распределяет трафик на сетевом уровне. BFF (backend-for-frontend) — шлюз под один тип клиента.

Кэшируйте, где чтение повторяется, а данные меняются медленно: кэш API на бэкенде (proxy/in-memory) и кэш на клиенте для пользователя. Инвалидируйте через TTL и/или событийно, когда запись обновляет ключи. Учитывайте холодный кэш и прогретый. Компромисс — задержка против устаревания.

Монолит проще разрабатывать, развёртывать и тестировать — внутрипроцессные вызовы, единая граница транзакции — но масштабируется целиком и становится хрупким с ростом. Микросервисы дают независимое развёртывание, масштаб по сервисам и автономию команд ценой сетевых задержек, распределённых транзакций и более тяжёлой эксплуатации. Выбирайте монолит для ранних продуктов; переходите при росте масштаба, команды или независимости релизов.

Делите по бизнес-способности или bounded context, чтобы сервис владел одной цельной областью и своими данными. Граница неверна, когда сценарий требует болтливой цепочки сервисов, два сервиса делят одну транзакционную запись или всегда разворачиваются вместе.

Независимость означает, что сервис может меняться и выпускаться сам по четырём осям. Код: свой репозиторий, без общей сборки. Данные: своя база только через его API. Деплой: выходит без передеплоя остальных. Релиз: функции выходят за версионированным API.

HLD (high-level design) — описание уровня архитектуры того, как будет построена система, для архитекторов, лидов и стейкхолдеров, чтобы согласовать решение до детального проектирования. Он содержит основные компоненты, интеграции и потоки данных, архитектурный стиль, ключевые нефункциональные решения и внешние зависимости. Он намеренно неглубок — детали реализации заполняет low-level design.

За: независимый деплой, масштаб по сервисам и автономия команд, когда монолит тормозит релизы. Против: 15 сервисов добавляют сеть, распределённые транзакции и нагрузку эксплуатации. Strangler: вынести один-два слабосвязанных сервиса первыми.

Базовые артефакты документации: описание бизнес-процесса; пользовательские сценарии; краткие описания бизнес-задач ПО; структура БД; схемы потоков данных, интеграций и сервисного взаимодействия; внешние интеграции; описание собственных API с версионированием; аутентификация/авторизация/идентификация; и матрицы ролей/пермишенов.

Основные стили — монолит (один развёртываемый блок), микросервисы (маленькие независимые сервисы), SOA (крупные сервисы на общей шине), event-driven (реагируют на события) и serverless (функции по требованию). Каждый меняет простоту на масштаб.

CQRS (Command Query Responsibility Segregation) разделяет сторону записи (команды) и чтения (запросы). Окупается, когда чтение и запись резко различаются по нагрузке или форме. Цена — модель чтения, синхронизируемая асинхронно, с eventual consistency.

Event Sourcing хранит состояние как append-only лог событий, а не только последний снимок. Состояние восстанавливают воспроизведением событий, что даёт полный аудит. Усложняет: запросы, эволюцию схемы и исправления через компенсирующие события.

Нет, ESB (enterprise service bus) — не единственное отличие. SOA использует крупные общие сервисы на центральной шине интеграции. Микросервисы мелкие, каждый владеет своими данными и общается точка-точка, значит, разница ещё и в гранулярности.

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

АИС (автоматизированная информационная система) собирает, обрабатывает и выдаёт информацию для задач организации. В терминах ГОСТ 34 она делится на функциональные подсистемы по бизнес-функции и обеспечивающие: техническое и программное обеспечение.