Избранное из глав "птицы".

Глава 2. Разделение компонентов.

Архитектурный квант - условно сервис, который деплоится отдельно.
Хотя несколько сервисов вполне могут представлять собой один квант, и часто это делают:

Например:
общая база данных => у вас один архитектурный квант
общий ui => у вас тоже один архитектурный квант )
есть оркестратор запросов => мб у вас тоже один квант ))

Динамический coupling между квантами

3 "силы", которые формируют пространство для принятия решений:
- взаимодействие между квантами - синхронное (вызывающий ждёт, чтобы продожить) или асинхронное (не ждёт)
- согласованность - атомарные транзакции или приемлемо eventual consistency
- координация - оркестратор (есть сервис, к-й отвечает за координацию) или хореография (нет координатора)

Понравилась табличка с вариантами, особенно horror )

Глава 3

О том, что тестируемость, развёртываемость, масштабируемость, доступность, отказоустойчивость лучше у небольших сервисов.
Поэтому если у вас проблемы с финансами, нужно срочно перейти на микросервисы (немного утрированный пример из главы 😁)

Так то это так мб, но возникают другие проблемы, и как будет с той же тестируемостью у системы в целом?

Впрочем, учебные примеры часто бывают немного странными. Допустим, всё же нужно разделиться, посмотрим )

#книги@anna_codes #arch_hard_parts@anna_codes