«Эволюционная архитектура», Нил Форд и др.

Время беспощадно ко всему, в том числе и к архитектуре ПО. Если ей не заниматься, то даже самая гибкая и изящная структура со временем превратится в «большой ком грязи».

Я наблюдал такие истории несколько раз, и мне всегда было интересно: как поддерживать архитектуру в качественном состоянии? Рисование «квадратиков» и сотрясание воздуха на созвонах не помогают — нужны реальные действия. Поэтому я решил прочесть (очередную) книгу Нила Форда и его коллег — «Эволюционная архитектура».

⭐️ О чём книга

Издание посвящено тому, как выстраивать архитектуру, способную сохранять целостность с течением времени. Авторы делятся конкретными подходами и инструментами для поддержания её жизнеспособности.

В книге раскрываются следующие темы: ➡️ В чем заключаются особенности построения эволюционной архитектуры. ➡️ Что такое фитнес-функции и как они помогают проектировщику. ➡️ Как автоматизировать управление архитектурой. ➡️ Как обеспечивать эволюцию данных. ➡️ Антипаттерны эволюционной архитектуры.

⭐️ 3 идеи из книги 🟡Данные должны эволюционировать вместе с кодом. Я неоднократно встречал системы, где разработчики создавали изящные сервисы по канонам DDD, но все они обращались к единой базе данных. В итоге получался «распределенный монолит». Проблема в том, что данные мигрировать гораздо сложнее, чем код, поэтому проектирование изменений стоит начинать именно с них.

🟡Влияние DevOps на архитектурную гибкость. Практики DevOps напрямую ускоряют эволюцию системы: чем быстрее и прозрачнее процесс поставки, тем легче внедрять архитектурные изменения, делая их атомарными. Проще говоря, появляется возможность «есть слона по частям», что значительно упрощает любую трансформацию.

🟡Механизмы контроля характеристик. По мере развития системы необходимы инструменты, оценивающие влияние изменений на ключевые параметры. Если архитектура поддерживает фитнес-функции, архитектор может определить критерии пригодности, которые будут автоматически защищать критически важные характеристики системы.

⭐️ Мои впечатления

У меня от книги остались смешанные чувства. Ключевая мысль авторов: архитектура неизбежно деградирует в процессе разработки, и наша задача — предотвратить этот распад. Очевидно, что в масштабных проектах ручной контроль невозможен, поэтому фитнес-функции становятся необходимостью.

Авторы подробно разбирают концепцию фитнес-функций, но, на мой вкус, излишне увлекаются философией, уделяя недостаточно внимания конкретным примерам реализации. Тем не менее, тезис об автоматическом мониторинге архитектурных показателей крайне важен. Это могут быть как простые метрики (процент покрытия кода тестами), так и структурные проверки (например, отсутствие циклов в графе зависимостей).

Стоит отметить, что авторы повторяют многие тезисы из своих предыдущих работ, поэтому искушенные читатели могут пропустить некоторые главы без потери смысла. И, конечно, их излюбленные термины вроде «коннасценции» или «афферентности/эфферентности» никуда не делись. Понятия точные, но в повседневной практике зачастую кажутся избыточными.

В целом книга заслуживает внимания. Не стоит ждать от неё «вау-эффекта», но несколько ценных инсайтов о выживании систем в долгосрочной перспективе вы точно получите.

Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.

А для тех, кто хочет читать с большей пользой, у меня есть статья с описанием моего процесса чтения и упражнениями.

➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog

В этом посте были ссылки, но мы их удалили по правилам Сетки