Архитектура программных систем

Из чего складывается хорошая граница в системе: связанность и связность как две силы, способы организовать код (по слоям или по фичам) и модульный монолит как разумная стартовая архитектура. Модуль показывает, что архитектура — это в первую очередь решение о границах, и что чёткие границы внутри одного процесса дешевле распределённой системы.

1. Связанность и связность: критерий границы
2. Организация кода: по слоям или по фичам
3. Модульный монолит как стартовая архитектура

Как сервисы обмениваются данными, не завися друг от друга во времени: синхронный вызов против асинхронного сообщения, брокеры RabbitMQ и Kafka и их разные модели, гарантии доставки и идемпотентность потребителя, паттерн outbox против проблемы двойной записи. Модуль строит модель надёжной интеграции, в которой отказ или задержка одного сервиса не валит остальные.

1. Синхронная и асинхронная интеграция
2. Брокеры: RabbitMQ против Kafka
3. Гарантии доставки и идемпотентность
4. Проблема двойной записи и паттерн outbox

Как система держит нагрузку: масштабирование вверх и вширь и почему без отсутствия состояния второе невозможно, балансировка нагрузки, слои кэширования и реплики на чтение, компромиссы согласованности из теоремы CAP и разбиение данных по узлам. Модуль связывает backend-навыки с проектированием системы целиком и её цены под ростом запросов.

1. Масштабирование и отсутствие состояния
2. Балансировка нагрузки
3. Кэш и реплики на чтение
4. Теорема CAP и согласованность
5. Разбиение и шардирование данных

Разбиение системы на отдельно разворачиваемые сервисы: когда и по какому принципу делить, как сервисы общаются (REST против gRPC, синхронно против асинхронно), кто координирует многошаговый процесс и как держать данные согласованными без общей транзакции через паттерн Saga. Модуль показывает, что микросервисы решают проблему масштаба команд ценой распределённости.

1. От монолита к микросервисам: когда и зачем
2. Межсервисное общение: REST и gRPC
3. Оркестрация против хореографии
4. Распределённые транзакции и Saga
5. База данных на сервис

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

1. Строительные блоки DDD
2. Агрегаты и границы согласованности
3. CQRS: разделение чтения и записи
4. Введение в event sourcing