Книга “Фундаментальный подход к программной архитектуре”. 450 с. 2023 г.
Авторы: Марк Ричардс, Нил Форд.
Первостепенно хотелось бы выделить структурированность предлагаемого материала.
Думаю данная книга вполне заслуживает звание учебника по архитектуре, т.к. дает знания о большинстве верхнеуровневых понятий программной архитектуры.
Кроме привычного оглавления вначале присутствует краткое содержание.
В предисловии - вся философия архитекторов ПО: деятельность базируется на аксиомах, как в математике, но они менее строги, т.к. большая скорость развития технологий влечет быстрое появление новых аксиом. И основная задача архитекторов: подвергать сомнению доставшиеся нам предположения и аксиомы.
“Каждая новая эра требует новых технологических приемов, инструментов, метрик паттернов и множество других изменений”.
Книга разделена на три части: Основы, Архитектурные стили и Технические приемы и гибкие навыки.
Долгое время говорилось, что архитектура - “это ТО, что изменить впоследствии весьма НЕ просто”.
Но с появлением микросервисов архитектура стала важнейшей особенностью дизайна, в смысле проектирования.
Еще один важный вопрос - анализ компромиссов. Чаще всего в работе архитектора не бывает двоичных вариантов выбора.
Легко увлечься определенной технологией или подходом, поэтому необходимо расширять свои знания постоянно, чтобы “точнее взвешивать” принимаемые решения, исключив оценочные суждения, “копать” не вглубь каждого подхода/технологии, а вширь, подбирая подходы по обеспечивающим допустимый результат характеристикам.
Авторы представляют определение архитектуры, как способ осмысления через структуру, свойства архитектуры, принципы проектирование и архитектурные решения.
Результатом деятельности архитекторов считается:
-принятие архитектурных решений;
-постоянный анализ архитектуры;
-своевременное следование последним тенденциям;
-контроль за выполнением принятых решений;
-обладание обширными знаниями и опытом;
-компетентность в нужной области бизнеса;
-владение навыками межличностного общения;
-четкое понимание политики компании.
Несколько цитат:
“Архитектура — это то, что невозможно загуглить”
“В архитектуре нет верных или неверных ответов, есть только компромиссы”
“Разработчиков притягивают сложности, как мотыльков огонь, и зачастую результат один и тот же”
Для себя полезным посчитал связь задач предметной области с архитектурными свойствами.
Заметил знакомые компоненты в высокоуровневом архитектурном разбиении по задачам предметной области. Не смотря на представленный авторами длинный список свойств при обсуждении ключевых свойств архитектуры, имхо верное упомянуто, что в реальности, с заказчиком, необходимо стремится к тому, чтобы список свойств получился максимально коротким.
Параметры архитектурных свойств обобщают в разного вида показатели и измеряют. При этом, надо еще понять, насколько качественным будет придуманный способ измерения.
Управление осуществляют посредством функции пригодности(фитнес функции).
Функцию пригодности определяют(если я правильно понял), как любой механизм или алгоритм, встраиваемый в ПО, дающий объективную оценку целостности какого-либо архитектурного свойства или сочетания архитектурных свойств.
Радует, что авторами признается маловероятность хорошего проектирования компонент и модулей изначально и упоминается об итерационном подходе к проектированию, как оно в жизни и бывает, когда заказчик периодически выкатывает требования, противоречащие первоначально созданному основанию.
И далее, по классике системного подхода каждый этап работы с компонентами после выявления и назначения требований происходит в цикле, уточняясь с каждой итерацией.
Был интересен список заблуждений при использовании распределенной архитекторы.
Ранее было понимание, что рисков и неудобств при такой реализации больше, а тут на тебе чек-лист для ответа на вопрос “На сколько нужно заморачиваться”.
Как найти приемлемые границы сервисов в микросервисной архитектуре?
Необходимо сфокусироваться на назначении, транзакциях и хореографии(коммуникация/балансировка).
Для обмена между сервисами важно подумать о протоколе, учесть разнородность архитектуры и интероперабельности (какими способами происходят взаимные вызовы)
Взял на заметку ADR - запись архитектурных решений, вернее предложенную в книге структуру.
Понравилась глава про анализ архитектурных рисков - просто и понятно, хоть завтра внедряй.
Метод риск штурма по организации коллективной работы и объективизации итоговой оценки напомнил покер планирования.
На этапе анализа изучения содержаний, данная книга показалась проще других, рекомендуемых ШСМ для белее детального погружения в архитектурный раздел системной инженерии.
Кто непосредственно занимается разработкой ПО и хочет погрузиться детальнее , узнать об эволюции, трендах, метриках и кейсах/опыте коллег продолжение/ смежная детальная информация в этих книгах:
- Эволюционная архитектура (Building Evolutionary Architectures)
- Современный подход к программной архитектуре, сложные компромиссы (Software Architecture: The Hard Parts)
- Software Architecture Metrics не нашел на русском (и она не упоминается в текущей книге)
Смежные посты
[СМИ-2024] Эволюционная архитектура
Рецензии на книги главы «Непрерывное принятие архитектурных решений»
upd: учел комментарии, убрал рекламный Shit, добавил отсебятины.
Соль убирать не стал, так как сам больше ценю резюме понравившихся смыслов важнее своих трактовок(от автора аутентичнее … или лаповее).
Структура, краткое содержание и вопросы для проверки фундаментальны.