Книга о построении эволюционных архитектур, т.е. архитектур продуктов, которые развиваются со временем. Не сказать, что полна революционных идей, и подчерпнул что-то прям новое, но в целом полезна.
В первых главах автор (их несколько, но думаю кто-то из них 🙂 ) рассуждает о том, что в современном мире программные системы не статичны — возможность развития и изменения в соответствии с меняющимися условиям бизнеса является важным требованием сама по себе. При этом любая архитектура программной системы должна удовлетворять своему списку -bilitys (например scalability / high availability / security / … ). Пусть мы определили, какие требования к архитектуре нашей системы и наш программный продукт удовлетворяет им в текущий момент, но если мы говорим о поддержке изменений и развития необходимо отслеживать, что все эти -bilitys продолжают соблюдаться. Для этой цели вводятся fitness functions — измеримые показатели соответствия каждому из -bilitys. Это могут быть время отклика веб страницы, время доставки товара, количество инцидентов, степень покрытия тестами и т.п. Мы встраиваем измерение этих характеристик или просто в наш мониторинг или если речь про характеристики кода — прямо в пайплайн, не позволяя им снижаться.
Далее он рассуждает о разных архитектурах и насколько легко они поддаются эволюции. Несколько легко для них отслеживать связи и зависимости, определять фитнес функции, писать функциональные тесты. Начинает с big ball of mud и через монолит, систему с интеграционной шиной, сервисную архитектуру доходит до микросервисной. В процессе часто упоминается DDD и присущие ему идеи, такие как bounded contexts.
Бегло пройдясь по эволюции данных (очень бегло, скорее просто упомянув что эволюция данных требует особого внимания и приведя пару примеров) автор переходит к рассуждениям о том, что усложняет эволюцию программных систем и какие частые ошибки и антипаттерны бывают тут. Основная мысль тут в принципе одна и повторяется в разных примерах — больше всего мешает эволюции софта сильная связанность и неявные зависимости.
Тут главное найти правильную и подходящую для конкретного проекта степень переиспользования кода — сильно переиспользуемый код усложняет развитие, но и писать одни и те же решения по многу раз и потом развивать их все по отдельности — проще, но в итоговой сумме может оказаться сильно трудозатратнее.
В последних главах автор рассуждает о том как внедрять эволюционные подходы к построению архитектуры в существующие проекты, а также надо ли это делать. И это очень важные мысли — во-первых, все эти подходы не бесплатны и требуют дополнительных затрат времени и мыслетоплива. Нет смысла применять их, если мы делаем проект, время жизни которого изначально строго ограничено. Во вторых, они имеют смысл начиная с определенного размера проекта (как по объему кода, так и по количеству людей в команде) и должны включать в себя не только технические, но и что важнее определенные организационные подходы. Слабая связанность, микросервисы и т.п. упрощают развитие ПО, только если за эти разные слабо связанные сервисы отвечают разные команды
В целом, повторюсь — потраченного на книгу времени не пожалел 🙂 Идея с фитнес-функциями вроде как лежит на поверхности, но тщательно проговоренная и подкрепленная примерами — особенно хороша.