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

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

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

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

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

3 "силы", которые формируют пространство для принятия решений:

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

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

Глава 3

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

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

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