Иерархия чистого кода. На пути к архитектуре ПО

В этой статье мы поговорим о хорошо структурированном коде и арихитектуре программного обеспечения. Для многих архитектор ПО — вершина карьеры разработчика, человек, который знает все, а архитектура — нечто необъятное, что можно познать только спустя многие годы в профессии. Мы попробуем разобраться, из чего складывается хорошая программа на разных уровнях абстракций и что же из себя представляет архитектура ПО.

Говоря об уровнях абстракций, я имею ввиду следующую иерархию:

На каждом уровне цель разработчиков и архитекторов добиться легко поддерживаемого и расширяемого приложения. Именно эту цель важно приследовать при разработке ПО. Казалось бы, без правильно работающего приложения, все это бессмысленно. Однако, с хорошо структурированным кодом не будет проблемы исправить работу приложения, а вот плохо написанную рабочую программу придется переписывать с нуля в случае изменения требований. Рассмотрим принципы успешного построения каждого из уровней. В этой статье я основываюсь на книге Роберта Мартина “Чистая архитектура”.

Хорошая программа начинается с чистого кода

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

Проблемы этого уровня называют дурными запахами кода. Приведу некоторые из таких проблем:

• Магические числа.
• Длинный метод.
• Дублирование кода.
• Ленивый класс.

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

Принципы дизайна классов

Разобравшись с низкоуровневыми проблеми, можно подниматься выше и решать задачи правильной организации функций и данных в классы и сочетания этих классов друг с другом. Этот уровень определяет все, из чего состоят ваши программные модули. Здесь вам могут помочь пять основных принципов объектно-ориентированного проектирования. Вместе они составляют акроним SOLID. Рассмотрим каждый из принципов по отдельности:

• Принцип единственной ответственности (SRP). Модуль должен иметь только одну причину для изменения (отвечать за одну группу пользователей – актора). Проблема может возникнуть, когда в одном классе содержатся публичные методы, используемые концептуально разными акторами. При этом, они могут обращаться к одним и тем же закрытым методам внутри класса. Тогда при внесении изменений в логику работы методов, относящихся к одной группе пользователей, она может непреднамеренно измениться и для другой группы. Поэтому необходимо разделять классы и модули по акторам, которых они обслуживают.
• Принцип открытости/закрытости (OCP). Сущности должны быть открыты для расширения и закрыты для изменения. Этот принцип говорит о том, что при расширении функциональности модуля, существующий код не должен меняться. Это одна из фундоментальных идей, к достижению которой нужно стремиться на всех архитектурных уровнях.
• Принцип подстановки Барбары Лисков (LSP). Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы. Стандартный пример невыполнения этого принципа — проблема “прямоугольник-квадрат”. Математически квадрат является прямоугольником, но, если подставить квадрат в объект типа прямоугольник, можно столкнуться с неожиданным поведением, изменяя его длину и высоту по отдельности.
• Принцип разделения интерфейсов (ISP). Лучше много интерфейсов, предназначенных для разных клиентов, чем один интерфейс для всех. Это позволит изменять только те сущности, которые этого действительно требуют.
• Принцип инверсии зависимостей (DIP). Зависимости в коде должны быть направлены не на абстракции, а на конкретные реализации. Следует избегать зависимостей и наследований от неустойчивых классов, которые могут часто меняться. Вместо этого нужно ссылаться на интерфейсы и абстрактые классы.

Принципы организации компонентов

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

Рассмотрим три принципа связности компонентов:

• Принцип эквивалентности повторного использования и выпусков. Единица повторного использования есть единица выпуска. Этот принцип требует, чтобы компоненты проходили процесс выпуска и получали версии. В один компонент должны объединяться классы c одной целью, которая будет выражена в очередном выпуске. По документации же пользователи и разработчики должны понимать, нужно ли им переходить на новую версию.
• Принцип согласованного изменения. В один компонент должны объединяться классы, изменяющиеся по одним причинам. Этот принцип эквивалентен SRP, но для компонентов. Идея заключения вместе сущностей, которые могут изменяться в одно и то же время и по одним причинам, является одной из ключевых идей архитектуры ПО, поэтому она проходит красной нитью по всем структурным уровням.
• Принцип совместного повторного использования. Не вынуждайте пользователей компонента зависеть от того, чего им не требуется. Главная мысль этого принципа в объединении в компоненты тех классов, которые имеют множественные зависимости друг от друга. Кроме того, нужно избегать слабых зависимостей от других компонентов — даже зависимость от одного редко используемого класса наверняка потребует повторной компиляции и тестирования всего компонента в случае изменений в зависимом.

Перечисленные принципы несколько противоречат друг другу и преследуют разные цели. REP стремится к объединению классов для обеспечения удобства пользователя, CCP — для удобства разработки и сопровождения, а CRP призывает разделять компоненты, чтобы избежать лишних выпусков. Задача архитектора — найти золотую середину среди них.

Теперь перейдем ко второй группе принципов. Сочетаемость компонентов:

• Принцип ацикличности зависимостей. Нельзя допускать циклов в графе зависимостей. Это позволяет разбить проект на компоненты, которые будут выпускаться независимо. При возникновении цикла между зависимостями для тестирования и выпуска новой версии придется отладить и подготовить все компоненты, входящие в цикл. Они превращаются в один большой компонент.
• Принцип устойчивых зависимостей. Зависимости должны быть направлены в сторону устойчивых компонентов. Нужно использовать ссылки на компоненты, которые будут редко меняться и избегать зависимостей от изменчивых компонентов. Это добавит гибкость в разработке, так как всегда нужны компоненты, которые можно легко изменять. Если же создать большое число зависимостей от такого компонента, эта возможность легких изменений испарится.
• Принцип устойчивости абстракций. Этот принцип проводит связь между устойчивыми и абстрактными компонентами. Компоненты, которые содержат интерфейс для высокоуровневой бизнес-логики, должны быть абстрактными и почти не меняться. Реализации же этого интерфейса должны быть неустойчивыми — избегайте множественных зависимостей от таких компонентов.

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

Архитектура системы

Итак, мы подобрались к самому верхнему уровню и готовы ответить на главные вопросы. Архитектура — это форма вашей системы. Она представляется набором высокоуровневых компонент, взаимосвязями между ними. А архитектор стремится поддерживать ее максимально доступной для изменений. Главное свойство хорошей архитектуры — гибкость, и добиться ее можно, придерживаясь следующей стратегии: как можно дольше иметь как можно больше вариантов.

Создание архитектуры состоит в проведении границ между программными элементами. Отделять границами нужно все, что не относится к бизнес-правилам. Это детали, выбор которых можно отложить и впоследствии без труда заменить. Например, это может быть ввод/вывод или хранилище данных. Границы могут не иметь физического представления — распологаться на уровне исходного кода. Такой вариант архитектуры называется монолитом. Также границы могут представлять из себя отдельные компоненты развертывания, локальные процессы или микросервисы.

Еще один признак хорошей архитектуры заключается в следующем: посмотрев на высокоуровневую структуру пакетов исходного кода вашего продукта, вы должны понимать, в чем суть вашего приложения. Если вместо того, чтобы увидеть, что это система документооборота или онлайн-магазин, вы видите только то, что это ASP.NET MVC или Spring приложение, то у вас проблемы. Архитектура должна отражать бизнес-правила и варианты использьвания, а фреймворки — это детали.

Все это приводит к многоуровневому варианту чистой архитектуры. На верхнем уровне находятся сущности системы. Каждая сущность представляет собой бизнес-правила предприятия — правила, которые действуют и в отсутствие электронного приложения. Ниже находятся варианты использования. Это бизнес-правила, которые относятся конкретно к вашему продукту. Далее следует уровень адаптеров интерфейсов. На нем данные из сущностей и вариантов использования преобразуются в формат удобный для внешних агентов. Это могут быть различные шлюзы, презенторы и т.д. Паттерн MVC целиком находится на этом уровне. На последнем же уровне находятся фреймворки, внешние хранилища и прочие детали.

Помимо разделения уровней границами есть еще одно правило, применимое к такой архитектуре. Зависимости в исходном коде должны быть направлены вверх, в сторону высокоуровневых политик. Это правило вытекает из тех принципов, что мы уже обсудили ранее. Такой вариант архитектуры позволит создать легко тестируемое и поддерживаемое приложение.

Written on February 6th, 2019 by Alexey Kalina