https://www.audible.com/pd/Fundamentals-of-Software-Architecture-Audiobook/B08X917VLR
Авторы начинают со стандартного блаблабла о важности архитектуры, о работе архитектора и т.п. Там в целом в книге много такого, так что я буду обозначать только те моменты, которые мне показались полезными, пропуская то, что не очень 🙂
Первой полезной главной внезапно оказалась глава о модульности. Казалось бы, ну что ещё можно сказать о модулях, связности и т.п. думал я — но оказалось, что учиться и узнавать новое никогда не поздно 🙂 После рассказа про то, что такое модульность, авторы переходят в характеристикам определяющим степень связности внутри ПО. Начинают с coupling (тут было все знакомо), но затем переходят к непроизносимым (и с неугадываемым на слух написанием) cohesion и сonnascence.
Cohesion — в отличие от coupling, показывающей степень зависимости модулей между собой — показывает степень взаимосвязи функций внутри модуля и может служить показателем того, не нужно ли разделить модуль на несколько.
Connascence — это более точная характеристика взаимозависимости, она возникает между двумя модулями, если изменения в одном требуют внесения изменений в другой, чтобы система в целом оставалась корректной. Она бывает разной степени — от простой зависимости от имени или типа, до более сложных зависимостей — от смысловых значений констант, от времени и порядка выполнения и др
Дальше авторы переходят к рассуждениям о том какие бывают архитектурные характеристики и о fitness functions для них. Материал сильно совпадает с книгой Building evolutionary architectures. Из нового (или упущенного мной при чтении той книги) — мысль о роли фитнес функций как инструмента управления (governance), когда архитектор непосредственно не пишет и не ревьюит код, но обеспечивает нужные характеристики через фитнес функции.
От самих характеристик разговор переходит на то, являются ли они характеристиками всей системы? Вводится понятие архитектурного квантума — части системы, которая обладает отличными от других частей НФТ. Тут мне показалось в книге присутствовал перекос в сторону — подумайте каким частями системы какие НФТ нужны и таким образом разбейте ее на разные квантумы, вместо — подумайте? правда ли разным частям вашей системы нужны разные НФТ, что потребует разбить ее на разные квантумы. Правильная мысль тут — если несколько выделенных вами квантумов используют одинаковый набор технологий и возможно даже общую бд — то точно ли итоговые НФТ у них получаются разные? Точно ли ваш код влияет на них настолько — если у вас супер scalable приложение, но при этом общая бд, без шардирования и возможностей кластеризации — уверены ли вы, что ваша система в целом scalable.
Следующей очень интересной главой была глава про компоненты, проектирование системы исходя из них. Не сказать, что что-то новое, но наводящее порядок в голове. Авторы пишут, что есть два основных подхода к выделению компонентов. Первый — исходя из технических характеристик (слоеная архитектура, mvc) — компонент работы с базой, компоненты бизнес логики, компоненты представления. Второй — исходя из бизнес-доменов, по заветам DDD. Оба имеют свои плюсы и минусы и какой выберете вы во многом должно зависеть от закона Конвея — как организованы люди у вас в компании. Если у вас отдельные отделы дба, бэкенда и фронтенда — вам ближе первый способ. Если же кроссфункциональные команды, отвечающие за отдельные части продукта — второй. Но верно и обратное, можно воспользоваться обратным законом Конвея и, если вы по каким-то причинам предпочитаете какой-то из этих подходов — надо переорганизовать команды, чтобы они соответствовали выбранной архитектуре.
Во второй части книги начинается описание архитектурных стилей. И начинается он просто огненно — упомянув, что базовым водоразделом между разными стилями является какая архитектура — монолитная или распределённая используется — авторы рассказывают о заблуждениях (fallacies), которые часто бывают при построении распределенных систем. Я просто перечислю их тут, а в книге к каждому заблуждению приводятся примеры и объяснения:
- сеть надёжна
- латенси равна 0 и ей можно пренебречь
- сетевой канал бесконечно широк
- сеть безопасна
- топология сети и распределенных сервисов неизменна
- существует только один администратор
- транспортные расходы пренебрежимо малы
После чего, видимо чтобы добить слушателей упоминают ещё сложности с распределенными транзакциями и логированием
На этой оптимистичной ноте происходит переход к рассказу о разных архитектурах и для начала — о слоеной архитектуре. Ничего особо нового тут не говорится, разве что отмечу мысль об опасности скатиться к sink hole — когда промежуточные уровни в подобной архитектуре не делают ничего, а просто передают запросы дальше. Также интересная мысль, что с такой архитектуры часто начинают, так как она требует минимального продумывания на первом этапе и упрощает ориентирование в кодовой базе, пока она небольшая (как в зеркало гляжусь при чтении этого)
Далее авторы рассматривают
Рipeline architecture — интересный подход, тоже монолитный, но несколько снижающий сложность и повышающий независимость отдельных компонентов (если только вы не наворотите сложную сеть этих фильтров)
Microkernel architecture — система с общим ядром и подключаемыми плагинами. Теоретически может быть хороша , когда разные плагины могут по-разному менять или расширять проведение. На практике — в какой-то момент новые фичи требуют расширения не предусмотренного заранее — что влечёт необходимость изменения и общего кода и часто всех плагинов.
Service based architecture — первая распределённая архитектура. Авторы предлагают ее называть далее макросервисной — сервисы большие, продукт состоит из 6-20 сервисов. Чаще всего при этом используется одна БД. При использовании одной БД важное тут, чтобы сервисы не были связаны друг с другом структурой БД.
Event driven architecture — архитектура на основе обработки потока событий. Описывается два варианта топологии — broker и mediator. В первом случае есть только общая инфраструктура для передачи сообщений, логика определяется самими обработчиками событий, можно легко добавить новые обработчики, не предусмотренные ранее. Но очень сложно обрабатывать ошибки, очень сложно понять завершилась ли операция и успешно ли. Второй — с центральным медиатором, который управляет процессом и контролирует ошибки, завершение процесса и т.п.
Также в этой главе описываются вопросы асинхронной обработки сообщений без потери данных, организации запроса-ответа в эту архитектуре, но подробнее эта тема рассматривается в недавно прочитанной Enterprise Integration Patterns. У нас события активно используются и в этой главе ничего особо нового для меня не было.
Space based architecture — очень интересная архитектура, в которой центральная БД заменяется распределенным реплицированным кешем, таким как hazelcast или apache ignite. Или если данных много или они очень часто обновляются — общим распределенным кешем. Плюс — высокая скорость работы, высокая доступность (в случае реплицированного кеша). Минус — высокая сложность, ограниченная применимость (далеко не все данные можно полностью поместить в оперативную память, ещё и дублируя ее на многих нодах). Но интересно.
Затем авторы проходятся по orchestration driven service based architecture — как примеру того, что осталось в прошлом, хотя было нацелено на казалось бы благородную цель — максимальный reuse кода и компонентов. В итоге это на практике выливалось в очень сильную связность и сложность внесения изменений, так как от одних компонентов зависит множество других.
И наконец приходят, как к ее противоположности, к микросервисной архитектуре. Честно говоря в главе про нее ничего особо нового не говорится — мысли те же, про связанность ее с идеями DDD и bounded contexts. Важный момент про необходимость избегать распределенных транзакций и что их наличие в большинстве случаев говорит о том, что сервисы выделены неверно — или слишком мелко или не по тем границам — всё требующее транзакции, за очень редкими исключениями, должно быть внутри одного сервиса.
Как выбрать архитектурный стиль из описанных — it depends — от приложения, требований, команды и т.п.
Последняя часть книги посвящена не архитектуре самой по себе, но работе архитектора:
- как документировать и описывать архитектуру — тут описывается идея ADR. Мне показалось что оно должно быть хорошо применимо для больших команд, хотя возможно что какие-то важные моменты было бы неплохо так документировать и у нас (где только время на это взять)
- анализ рисков, предлагается оценивать риски по метрике, характеризующей расположение риска на шкалах критичности и вероятности. Важная мысль — любая новая, неизвестная технология — это всегда high risk
- насколько архитектор должен быть включен в работу команд, как найти правильный баланс на шкале control freak — armchair architect
- базовые техники переговоров — основная мысль тут, что архитектурные решения надо не спускать сверху, а продавать разработчикам, объясняя зачем они приняты и по возможности давая разработчикам достаточно информации, чтобы они сами пришли к тому решению, которое считает правильным архитектор