Чистая архитектура. Искусство разработки программного обеспечения

Книга небольшая, 350 страниц, осилил с первого раза. Забегая наперед, скажу, что ожидания от книги совсем не совпали с реальностью - книга, скорее, для разработчиков, для архитекторов, которые кодят. Для системных аналитиков книгу может быть интересно прочитать, но реальной пользы, информации, которую можно было бы применить в работе, в ней процентов на 40-50.

Важный нюанс - книга пропитана историзмом и отсылками к прошлому, к истории программирования и развития ИТ отрасли в целом.

Первая и вторая главы - вводные, в них про то, что такое архитектура, в чем ее цель, в чем важность архитектуры, и как хорошая архитектура влияет на экономику компании. Польза от прочтения довольно условная, как и от любых вводных глав.

Глава с 3 по 6 про парадигмы программирования - структурное, объектно-ориентированное и функциональное. Из структурного программирования появились операторы if\then\else\while и сам подход декомпозиции кода на отдельные функции. Объектно-ориентированное программирование дает нам контроль над зависимостями в коде. Функциональное программирование накладывает ограничение на изменение переменных. Ради общих знаний и расширения кругозора стоит прочитать.

Дальше на протяжении нескольких глав описываются принципы SOLID.

В главе 7 раскрывается принцип единственной ответственности (Single responsibility principle) - модуль должен иметь одну и только одну причину для изменения. Или, иначе говоря, модуль должен отвечать за одного и только одного актора. Глава полезная, стоит прочитать - может пригодиться при проектировании API.

В главе 8 раскрывается принцип открытости\закрытости (Open-closed principle), который заключается в том, что программные сущности должны быть открыты для расширения и закрыты для изменения. Иными словами, можно расширять поведение сущностей без изменения самих сущностей. Глава тоже полезная, тоже может пригодиться при проектировании API, а именно при решении проблемы обратной совместимости.

В главе 9 описывается принцип подстановки Барбары Лисков (Liskov substitution principle). Принцип трудноформулируемый, поэтому ограничусь тем, что на работу системного аналитика он никак не влияет.

В главе 10 раскрывается принцип разделения интерфейсов (Interface segregation principle), призывающий избавляться от лишних зависимостей. Глава полезная, может пригодиться при проектировании архитектуры вашего продукта.

В главе 11 раскрывается принцип инверсии зависимости (Dependency inversion principle) - код, реализующий высокоуровневую политику, не должен зависеть от кода, реализующего низкоуровневые детали. Глава не очень применимая к работе системного аналитика, но прочитать будет интересно.

Глава 12 посвящена истории развития компонентов как единиц развертывания - jar файлов для Java, gem файлов для Ruby, и так далее. Сильно вчитываться не во что. Важно: здесь и далее слово "компонент" можно заменить на более привычное "сборка".

В главе 13 обсуждаются принципы связности сборок:

• REP - принцип эквивалентности повторного использования\релиза
• CCP - принцип согласованности изменения
• CRP - принцип совместного повторного использования

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

В главе 14 продолжается обсуждение сборок (компонентов) в плане их сочетаемости. Рассказывается про то, что зависимости кода от изменений в другом коде - это плохо, как это вылечить, а также, что тяжело изменяемые компоненты не должны зависеть от легко изменяемых компонентов, иначе они также станут тяжело изменяемыми. Аналогично предыдущей главе, прочитать можно, но в работе вы вряд ли это сможете применить.

В главе 15 снова рассказывается про архитектуру - каково ее предназначение, каково ее влияние на разработку, на развертывание, эффективность работы самой системы и ее сопровождение. Глава довольно общая, и с историческим экскурсом, но полезная к прочтению.

В главе 16 продолжается обсуждение того, что должна обеспечивать хорошая архитектура, а также как можно разделить систему на сравнительно независимые части, чтобы соблюсти обеспечиваемые характеристики системы (простота разработки, сопровождения и развертывания). Для меня эта глава была этаким тизером к отдельным книгам по проектированию микросервисной архитектуры. В общем, прочитать будет полезно.

В главе 17 говорится про архитектурные границы, отделяющие части системы друг от друга, о том как их проводить, где и когда. В 18 главе эта тема продолжается сравнением монолита, границ на уровне сборок и отдельных сервисов.

19 и 20 главы про политики и бизнес правила, а также про примеры применения принципов SOLID. Вроде бы термины крайне близки к документации, которой мы занимаемся, но осадок после прочтения остался крайне мутный.

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

22 глава называется так же как и книга, и в ней раскрывается основная идея, к которой нас подводили последние 5-7 глав. Чистая архитектура - это луковица, в которой каждый внешний слой луковицы зависит от ближайшего внутреннего. Само собой стоит прочитать главу, ради которой, как я понимаю, и была задумана вся книга :)

С 23 по 26 главу описываются конкретные паттерны проектирования на уровне кода. Если вы не разработчик, то главы можно смело пропускать.

В 27 главе говорится про сервисы и то, что архитектурные границы не всегда совпадают с границами самих сервисов, иногда проходя через них. А для преодоления проблем, связанных с этой оказией, сами сервисы нужно проектировать в соответствии с принципами SOLID. 

В 28 главе говорится про тесты и про их проектирование без отрыва от контекста системы.

29 глава, как я понимаю, была написана не автором, и посвящена архитектуре кода встраиваемых (embedded) устройств. Для меня полностью мимо.

В 30 главе снова возвращается автор, и разговор идет про базы данных и про то, что БД с точки зрения архитектуры является не полноценной сущностью, а незначительной деталью.

В 31 главе высказывается аналогичная позиция относительно Веба в контексте разработки 90-х годов - начала нулевых.

В 32 главе та же мысль относительно фреймворков, также описываются риски слишком плотной привязки к конкретному фреймворку.

В 33 главе приводится коротенький пример по созданию архитектуры для продукта - сайт, продающий обучающие видео. В 34 главе снова другим автором приводится более полный пример с разными подходами к проектированию кода. Пример, опять же, очень (для меня слишком) конкретный.

На этом все - дальше идет довольно обширное заключение в виде архитектурной археологии на много лет вглубь (от 70-х до 90-х). Читается сравнительно интересно, но на всем протяжении заключения где-то на фоне зудела мысль “зачем мне это”.

Если честно - книга мне не понравилась, что, к сожалению, становится довольно заметно к концу обзора. С другой стороны, справедливым будет заметить, что я как специалист и не являюсь целевой аудиторией этой книги.

В качестве альтернативного мнения предложу также ознакомиться с обзором этой же книги от коллеги по цеху из Тинькофф, ему, кажется, книга понравилась больше, чем мне: https://habr.com/ru/companies/tinkoff/articles/652999/