Книга рассказывает о построение эволюционной архитектуры сервиса. Под эволюционной архитектурой подразумевается способность к адаптации при внешних изменений. Для этого вводиться понятие фитнес функции по аналогии с генетическими алгоритмами. Для выбора верных фитнес функций архитектор должен определиться со списком -остей/-ilites сервиса.
Фитнес функции мы не просто определяем, но ещё и автоматизируем. Например, если нам нужно соблюсти слабую связность, то мы пишем линтеры для связи модулей или выдаём api-ключи к сервисам. Если мы хотим выдерживать определённую нагрузку, то можно в рамках деплоя прогонять нагрузочные тесты или бенчмарки, чтобы следить за соблюдением критерия. То есть, мы должны прописывать контракты с помощью кода, а дальше следить за их изменениями.
В книге всячески пытаются привести к мысли, что микросервисы наше всё, а вот монолит рано или поздно развалиться. Происходит это потому что количество требований к сервису возрастут, а большое количество требований приведёт к конфликтам. Конфликты будут в любом случае, но вопрос в их количестве.
Для декомпозиция монолита необходимо правильно соотнести для каких целей мы это делаем, и какие характеристики должны получить в конце. Перед тем, как приступать к этой задаче, стоит улучшить разделение на модули внутри монолита.
Главные чеклисты из книги:
- A fitness function review, с которого стоит начать проработку архитектуры. Так как даже в виду отсутствия изначально фитнес функций, мы начнём их писать.
- Culture questions from architect
- И, конечно, The list of -ilities
Цитаты
- 202209022221: architects must determine the most important -ilities.
- 202209071935: the list of -ilities
- 202209181625: finding the correct service granularity is key for decomposing.