Обзор на книгу Нила Форда и компании “Современный подход к программной архитектуре” (”Software Architecture: The Hard Parts”).
Если бы меня попросили дать название этой книге, то я бы назвал её “Большая книга о компромиссах в архитектуре ПО”. Команда авторов написала увесистый талмуд из почти 500 страниц о том, что в архитектуре не бывает лёгких и правильных решений, бывают только грамотно подобранные компромиссы.
«Всё — яд, всё — лекарство; то и другое определяет доза». Парацельс
Коротко о главном
- Книга о компромиссах в архитектуре ПО
- Рассматривается множество проблем архитектуры от модульности до распределённых транзакций
- Довольно объёмная, но легко читается
- В начале каждой главы приводится пример из реального мира
Я совершил небольшую ошибку, начав своё знакомство с творчеством Нила Форда с этой книги. Фактически она является продолжением “Fundamentals of software architecture” и авторы очень часто на неё ссылаются. Но это не повлияло на качество самой книги, поэтому в целом можно начинать и с неё.
Книга построена в интересном смешанном формате художественной и технической литературы. По ходу чтения мы вместе с командой вымышленного бизнеса проходим процесс эволюции архитектуры от болезненного монолита к микросервисам. Мне было так читать гораздо удобнее, потому что в начале каждой главы я получал кусочек бизнес-контекста и пример проблемы из реального мира. Так гораздо легче воспринимать информацию.
Читать было интересно. Несмотря на не самые простые темы, книга очень хорошо написана (и, что удивительно, переведена). Отдельным плюсом можно выделить большое количество рисунков/графиков/схем, которые сильно упрощают понимание происходящего.
Книга мне понравилась, и я почерпнул для себя много полезного. Пожалуй, самый главный урок — сложность компромиссов. Я и раньше прекрасно понимал, что в архитектуре не бывает простых решений, но после прочтения книги я по-новому взглянул на слово «компромисс». На самом деле компромиссы есть в каждом нашем решении (и это касается не только работы). Книга выводит компромиссы на передний план и показывает, что за любое решение так или иначе приходится платить. Мы всегда платим за свой выбор — за монолит, за микросервисы, за SQL, за NoSQL, за любую технологию. И наша задача заключается в том, чтобы выбрать наиболее приемлемый и подходящий компромисс.
Также особенно ценной для меня оказалась глава по построению саг. Сага - это распределённая многошаговая транзакция, части которой выполняют разные микросервисы. Раньше я знал только один вид саг: синхронная сага с оркестрацией и строгой согласованностью. Авторы же описывают 8 видов саг в зависимости от конфигураций:
- Взаимодействия: синхронные/асинхронные
- Согласованность: строгая/нестрогая
- Координация: оркестрация/хореография
В процессе чтения оказалось, что часть из этих саг я уже применял, просто не знал, что это так называется и уже кем-то описано. Все виды саг описаны очень подробно, и у каждого вида есть свой перечень преимуществ, недостатков и характеристик. Например, описанная мной выше сага называется «Эпическая сага», и её недостатки — низкая скорость, высокая связность и низкая масштабируемость.
Также авторы акцентируют внимание на том, что архитектура служит бизнесу, а не наоборот. Грамотно построенная архитектура ускоряет TTM фич, что для некоторых бизнесов критично. Если бизнес работает в высококонкурентной среде, то для него релизы раз в два месяца могут быть медленной и мучительной дорогой в ад. Поэтому бизнес и готов идти на компромиссы (да, и тут они) - например, местами отказываться от строгой согласованности в пользу повышенной скорости обработки и масштабируемости. При работе над архитектурой, будь то перестройка системы или просто предложение по улучшению, всегда нужно помнить о главной цели - сделать бизнесу жизнь проще и удобнее.
Также отмечу несколько недостатков книги:
- Некоторые аргументы крайне спорные (что вполне нормально в контексте книги).
- Очень поверхностно покрыты темы применения DDD и хранения данных.
- Чересчур много отсылок на предыдущую книгу, авторы как бы намекают на “купи-купи”.
- Назвать эту книгу глубокой - сложно. Скорее, это базовое введение в архитектуру. Книга всё-таки довольно поверхностная.
В заключение приведу несколько случайных интересных тезисов:
- Архитекторы не должны постоянно искать “серебряные пули”.
- Без постоянной работы любая база кода постепенно скатится в “большой ком грязи”.
- Разделение базы данных на четко определённые ограниченные контексты помогает контролировать критические изменения в базе данных.
- При использовании монолитной БД все данные должны соответствовать её типу, что может приводить к решениям, неоптимальным для определённых типов данных.
- Гранулярность определяется не количеством классов или строк кода, а функциями, возложенными на сервис. Вот почему так сложно добиться правильной гранулярности.
- Тщательно продумывая инкапсуляцию и контракты, архитекторы могут ограничить количество критических изменений и уменьшить хрупкость архитектуры.
- В общем случае считается, что сервис, выполняющий операции записи в таблицу, является владельцем этой таблицы. Однако совместное владение усложняет это простое правило!
Выводы
- Книга - отличная. Настоятельно рекомендую.
- Материал не для новичков, целевая аудитория - более опытные специалисты (middle/senior и выше).
- Полезна будет даже опытным и знающим спецам, а для тех, кто только начал своё погружение в архитектуру, станет настоящей кладезью информации.
- Хорошо переведена и можно смело читать на русском.
- Отдельный большой плюс - много схем/графиков/диаграмм, которые иллюстрируют
Моя оценка
10/10.