INTERLAB
Как делать · 08

Архитектура ПО

SOLID, паттерны, чистая архитектура, монолит и микросервисы, события, API, кэш и multi-tenant SaaS.

Прочитано: 0 / 10Основы архитектурыSOLIDПаттерны проектированияЧистая архитектураМодульный монолит и микросервисыСобытийная архитектура и очередиПроектирование APIКэшированиеМультитенантный SaaSПроектирование систем

Основы архитектуры

  1. Основы✓

    Архитектура ПО: что это и какие решения в неё входят

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

    Средний · 9 мин чтения

SOLID

  1. Основы✓

    SOLID на понятных примерах

    SOLID — пять принципов объектно-ориентированного проектирования, собранных Робертом Мартином: единственная ответственность (S), открытость/закрытость (O), подстановка Лисков (L), разделение интерфейсов (I) и инверсия зависимостей (D). Все пять отвечают на один вопрос: как устроить код, чтобы изменение в одном месте не ломало другие и чтобы части можно было тестировать по отдельности. Это эвристики, а не законы: у каждой абстракции есть цена, и применять принцип стоит там, где изменения действительно происходят.

    Средний · 8 мин чтения

Паттерны проектирования

  1. Основы✓

    Паттерны проектирования, которые реально нужны

    Паттерн проектирования — именованное типовое решение повторяющейся задачи: Strategy подменяет алгоритм, Adapter переводит чужой API в ваш интерфейс, Factory создаёт объект по конфигурации, Observer рассылает события подписчикам, Decorator добавляет поведение вокруг вызова, Repository прячет хранилище, Builder собирает сложный объект по шагам. Ценность паттерна — в общем словаре команды и в задаче, которую он решает. Если задачи нет — например, у правила всего одна реализация, — паттерн только добавляет кода.

    Средний · 8 мин чтения

Чистая архитектура

  1. Глубокий разбор✓

    Чистая архитектура: зависимости внутрь и границы модулей

    Чистая архитектура — способ организовать код так, чтобы бизнес-правила не зависели от фреймворка, базы данных и внешних сервисов. Её главное требование — правило зависимостей: импорты в исходном коде направлены только внутрь, от адаптеров к сценариям (use case) и сущностям, а ядро общается с внешним миром через интерфейсы-порты, которые само и объявляет. Компилятор TypeScript нарушение этого правила не замечает, поэтому его проверяют инструментом в CI — например, dependency-cruiser или ESLint.

    Продвинутый · 10 мин чтения

Модульный монолит и микросервисы

  1. Сравнение✓

    Модульный монолит или микросервисы

    Для большинства новых продуктов разумный старт — модульный монолит: одно приложение и одно развёртывание, но модули с публичным API, собственными данными и автоматической проверкой границ. Микросервисы дают независимое развёртывание и автономию команд, но добавляют сетевые вызовы, итоговую согласованность данных и эксплуатационную сложность — Мартин Фаулер называет это «премией за микросервисы». Выделять сервис стоит тогда, когда граница модуля устоялась, а у его части системы появились отдельная команда или особые требования к масштабу, доступности или безопасности.

    Продвинутый · 10 мин чтения

Событийная архитектура и очереди

  1. Глубокий разбор✓

    Событийная архитектура и очереди сообщений

    Событийная архитектура связывает части системы сообщениями: сервис фиксирует факт («заказ оформлен») и публикует событие, а заинтересованные сервисы реагируют сами, не блокируя исходный запрос. Брокеры дают доставку «хотя бы один раз», поэтому надёжная схема держится на двух приёмах: transactional outbox — событие пишется в базу в той же транзакции, что и данные, — и идемпотентный потребитель, который распознаёт повтор по id сообщения. «Ровно один раз» для внешних эффектов получается только так: повторы допускаются, но не меняют результат.

    Продвинутый · 12 мин чтения

Проектирование API

  1. Руководство✓

    Проектирование API: ресурсы, версии, ошибки, пагинация

    Удобный API строится вокруг ресурсов-существительных, использует методы HTTP в том смысле, который задаёт RFC 9110, отвечает точными кодами и ошибками в формате Problem Details (RFC 9457), листает большие списки курсором и развивается, не ломая клиентов. Эти соглашения фиксируют в спецификации OpenAPI 3.1 до написания кода, проверяют линтером, а реализацию — тестами на соответствие контракту.

    Средний · 15 мин чтения · практика ~1–2 ч

Кэширование

  1. Глубокий разбор✓

    Кэширование и инвалидация

    Кэш — это копия данных ближе к потребителю: в браузере, на CDN, в памяти процесса, в Redis или в самой базе. Архитектурные решения сводятся к трём вопросам: на каком уровне хранить копию, как её заполнять (cache-aside, read-through, write-through) и как узнавать, что она устарела (TTL, событие об изменении, новая версия ключа). Отдельная опасность — cache stampede, когда истёкший популярный ключ одновременно отправляет в базу сотни запросов; от неё защищают блокировка на перестроение и отдача устаревшего значения на время обновления.

    Продвинутый · 11 мин чтения

Мультитенантный SaaS

  1. Глубокий разбор✓

    Multi-tenant SaaS: изоляция данных арендаторов

    Multi-tenant SaaS обслуживает многих клиентов-арендаторов одной системой, и главное требование — данные одного арендатора никогда не видны другому. Самая экономная модель — общая схема с колонкой tenant_id во всех таблицах; в PostgreSQL её страхует Row-Level Security: политика по tenant_id фильтрует строки в самой базе, даже если в запросе приложения забыли условие. Отдельные схемы или базы на арендатора дают более сильную изоляцию ценой эксплуатации, а RLS обходят суперпользователь, роли с BYPASSRLS и владелец таблицы без FORCE.

    Продвинутый · 12 мин чтения

Проектирование систем

  1. Пошаговый урок✓

    System design на примере: сервис записи и масштабирование

    System design — это путь от требований к архитектуре, где каждое решение обосновано цифрами и ограничениями. Для сервиса онлайн-записи главное узкое место — не нагрузка, а корректность: два клиента не должны занять одно время, и эту гарантию надёжнее всего отдать базе данных через ограничение EXCLUDE. Уведомления через outbox, кэш расписания, реплики и секционирование добавляются по мере роста, когда этого требуют метрики.

    Продвинутый · 14 мин чтения · практика ~3–6 ч

Траектории с этим направлением

Java · 6 →Spring Boot · 7 →Архитектура ПО · 9 →API и интеграции · 8 →← Все направления
Расскажите о задаче — мы изучим запрос и свяжемся с вами

Есть задача?
Обсудим и оценим — бесплатно.

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

  • Оценка объёма и рисков до старта
  • NDA — по вашему или нашему шаблону
  • Старт работ в течение недели
Написать в WhatsApp

Не присылайте через форму пароли, ключи доступа и исходный код — безопасную передачу доступа обсудим отдельно.

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