Предисловие
Почему я перечитываю эту книгу? Я уже читал «Чистую архитектуру», но тогда мне не хватало проектной практики, проб и ошибок, поэтому понимание казалось поверхностным. Во время работы мне наконец довелось столкнуться с реальными проектами и требованиями. Ещё удачнее оказалось то, что наша команда использовала именно чистую архитектуру — точнее, сочетание событийной разработки, DDD и чистой архитектуры. Подробнее о DDD я расскажу позже. Я перечитал книгу 📚 и многое из неё вынес. В этой серии я попробую изложить собственное понимание чистой архитектуры; точнее будет назвать её читательскими заметками для коллег.
Книгу можно найти здесь: Чистая архитектура — Роберт К. Мартин — WeChat Read (qq.com)
Серия будет следовать структуре глав книги и постепенно углубляться в тему вместе с автором. Поскольку это повторное чтение, я неизбежно буду обращаться и к другим частям книги. Если встретится что-то непонятное или незнакомое, скорее всего, эта тема рассматривается в следующих главах.
Начнём.
Что означают дизайн и архитектура
По существу, между дизайном и архитектурой нет различия: низкоуровневые детали проектирования и высокоуровневая архитектура вместе определяют программную систему.
Конечная цель архитектуры ПО — удовлетворять потребности в создании и сопровождении системы с минимальными трудозатратами. Поэтому затраты позволяют оценивать качество архитектурного решения.
Система, поспешно созданная без продуманного проектирования, может превратиться в запутанный клубок. При её развитии качеством кода и улучшением структуры долгое время пренебрегают. Внимательное проектирование архитектуры в определённой мере помогает избежать такого состояния и тем самым снизить затраты.
У разработки ПО есть две важные особенности:
- Чтобы двигаться быстро, сначала нужно двигаться устойчиво.
- Излишняя самоуверенность приводит лишь к тому, что переработка архитектуры попадает в ту же ловушку, что и исходный проект.
Два измерения ценности
У программной системы есть два вида ценности:
- Поведенческая ценность: заставить машину работать заданным образом и приносить или увеличивать прибыль пользователей системы.
- Архитектурная ценность: ПО должно быть достаточно гибким, а стоимость его изменения — зависеть от масштаба требований, а не от их формы.
Как понимать масштаб и форму требований? На мой взгляд, масштаб — это приблизительный объём требований и соответствующая предметная область, а форма — конкретные детали этих требований.
Какое измерение ценности важнее? Автор считает архитектурную ценность более важной, чем поведенческую, потому что:
- Если программа работает, но её нельзя изменить, при изменении требований она перестанет работать должным образом. Исправить её для новых условий также не получится. В результате её ценность станет нулевой.
- Если программа пока не работает правильно, но её легко изменить, исправить её и затем приспосабливать к новым требованиям должно быть несложно. Такая программа будет продолжать создавать ценность.
Общая ошибка бизнеса и разработчиков — не отделять действительно срочные и важные функции от срочных, но неважных. В результате важные архитектурные вопросы уступают место неважным поведенческим функциям.
Именно разработчики отвечают за баланс между важностью архитектуры системы и срочностью функциональных требований.
Примечание: подобные проблемы возникают и между командами разработчиков. Например, некоторые фронтенд-команды считают, что бэкенду достаточно предоставить набор простых интерфейсов, не осознавая важности качественного проектирования.
Продолжать бороться за хорошую архитектуру ✊
Если пренебрегать архитектурной ценностью, сопровождать систему станет всё труднее, пока однажды её уже нельзя будет изменить. Такое состояние означает, что команда разработки недостаточно отстаивала свою позицию перед заказчиками требований и не выполнила собственные обязанности.