Использование компьютерных систем становится все более распространенным и необходимым в обществе. Начиная с повседневных задач, таких как заказ еды по мобильному телефону и проведение банковских операций, и заканчивая спорадическими обследованиями с помощью визуализации, используется программное обеспечение. Чтобы поддерживать этот растущий спрос, необходимо производить и поддерживать программное обеспечение в рамках адекватных затрат, направляя его рост и оптимизацию без ущерба для того, что уже разработано.
Программная инженерия — это инженерная дисциплина, занимающаяся всеми аспектами производства программного обеспечения, основными видами деятельности которой являются спецификация, разработка, проверка и эволюция программного обеспечения (SOMMERVILLE, 2010). Поскольку программное обеспечение является абстрактным и не ограничено физическими законами, это упрощает разработку программного обеспечения. Подобно тому, как это упрощение дает разработчику возможность строить приложения оптимизированным способом, отсутствие ограничений может также превратить программное обеспечение в нечто сложное и трудное для сопровождения.
Как физические конструкции состоят из более мелких компонентов, таких как кирпич, бетон или дерево, так и программные конструкции состоят из программных компонентов, которые состоят из других программных компонентов, и оба типа конструкций имеют архитектуру, чтобы сохранить эту конструкцию прочной и безопасной. Важнейшим понятием программной инженерии для этой статьи является понятие архитектуры программного обеспечения. Архитектура программного обеспечения компьютерной программы или системы — это структура или структуры системы, которая включает в себя компоненты программного обеспечения, внешне видимые свойства этих компонентов и отношения между ними (BASS; CLEMENTS; KAZMAN, 2012).
Изменения, происходящие в процессе разработки программного обеспечения, неизбежны, и хорошая архитектура направлена на сокращение времени выполнения этих изменений, что, соответственно, снижает финансовые затраты и усилия. Архитектура должна не только соответствовать непосредственным требованиям пользователей, разработчиков и владельцев, но и оправдывать эти ожидания с течением времени (MARTIN, 2017).
Подобно тому, как в архитектуре зданий существуют различные стили, такие как классический, романтический и барокко, в архитектуре программного обеспечения существуют такие архитектурные типы, как архитектура клиент-сервер, луковая архитектура и чистая архитектура. Однако все архитектуры программного обеспечения имеют общую цель — разделить программное обеспечение на слои, имея по крайней мере один слой для бизнес-правил и один для пользовательского и системного интерфейсов (MARTIN, 2017).
Архитектура должна не только отвечать требованиям пользователей, разработчиков и владельцев в данный момент времени, но и соответствовать этим ожиданиям с течением времени. Роберт МАРТИН (2017) предложил архитектуру Clean Architecture с целью содействия реализации целостных, независимых от технологий систем и благоприятствования повторному использованию кода. Далее мы рассмотрим эту архитектуру более подробно.
Чистая архитектура
Концепция чистой архитектуры была определена Робертом К. Мартином (MARTIN, 2017) в его книге под названием «Чистая архитектура: руководство ремесленника по структуре и дизайну программного обеспечения». В этой архитектуре системы можно разделить на два основных элемента: политика и детали. Политика — это бизнес-правила и процедуры, а детали — это элементы, необходимые для реализации политики.(MARTIN, 2017) Именно с этого разделения Чистая архитектура начинает отличаться от других архитектурных паттернов. Архитектор должен создать способ, чтобы система распознала политику как основной элемент системы, а детали — как элементы, не имеющие отношения к политике.
В чистой архитектуре нет необходимости выбирать в начале разработки базу данных или фреймворк, потому что все это детали, которые не мешают политике и, следовательно, могут быть изменены со временем.
Отдел ответственности
В Чистой архитектуре существует четко определенное разделение слоев. Архитектура независима от фреймворка, то есть внутренние слои, содержащие бизнес-правила, не зависят от сторонних библиотек, что позволяет разработчику использовать фреймворк как инструмент и не адаптировать систему под спецификации определенной технологии. Другими характеристиками чистой архитектуры являются: тестируемость, независимость пользовательского интерфейса, независимость от базы данных и независимость от любого внешнего агента (бизнес-правила не должны знать ничего об интерфейсах внешнего мира).
Для иллюстрации всех этих понятий была создана диаграмма, представленная на рисунке ниже.
Каждый круг рисунка представляет собой отдельную область программного обеспечения: в самой внутренней части — политики, а в самой внешней — механизмы.
Основным правилом для чистой архитектуры является правило зависимостей, которое гласит, что зависимости исходного кода всегда должны быть направлены только внутрь, т.е. в сторону политик более высокого уровня. При этом можно сказать, что элементы внутреннего круга не могут иметь никакой информации об элементах внешнего круга. Классы, функции, переменные, формат данных или любая сущность, объявленная в крайнем круге, не должна упоминаться в коде крайнего круга.
Самый внутренний круг — Entities, в нем собраны бизнес-цели приложения, содержащие наиболее общие и высокоуровневые правила. Сущность может быть набором структур данных и функций или объектом с методами, если эта сущность может использоваться несколькими приложениями. Этот слой не должен изменяться под воздействием изменений в крайних слоях, т.е. никакие операционные изменения в любом приложении не должны влиять на этот слой.
Слой сценариев использования содержит специфические для приложения бизнес-правила, группирующие и реализующие все сценарии использования системы. Варианты использования организуют поток данных, поступающих к субъектам и от них, и направляют субъекты в применении важнейших бизнес-правил для достижения целей варианта использования (MARTIN, 2017). Этот слой также не должен быть затронут внешними слоями, и его изменения не должны влиять на слой сущностей. Однако, если детали сценария использования изменятся, это повлияет на часть кода в этом слое.
Слой интерфейсных адаптеров имеет набор адаптеров, которые преобразуют данные в формат, наиболее удобный для окружающих его слоев. Другими словами, он берет данные, например, из базы данных и преобразует их в формат, наиболее удобный для слоев сущностей и сценариев использования. Можно также использовать обратный путь преобразования — от данных во внутренних слоях к внешним слоям. Ведущие, представления и контроллеры относятся к этому слою.
Внешний слой диаграммы обычно состоит из фреймворков и баз данных. В этом слое находится код, который устанавливает связь со слоем интерфейсных адаптеров. Все детали остаются в этом слое, веб — это деталь, база данных — это деталь, и все эти элементы остаются в самом внешнем слое, чтобы не создавать помех для других (MARTIN, 2017).
Но если слои настолько независимы, как осуществляется связь между ними? Это противоречие разрешается с помощью принципа инверсии зависимостей. Роберт К. МАРТИН (2017) показывает, что можно организовать интерфейсы и отношения наследования так, чтобы зависимости исходного кода были противоположны потоку управления в нужных точках. Если сценарию использования необходимо связаться с ведущим, этот вызов не может быть прямым, так как это нарушит правило зависимости, поэтому сценарий использования вызывает интерфейс из внутреннего круга, а ведущий во внешнем круге, который выполняет реализацию. Эта техника может быть использована между всеми уровнями архитектуры. Данные, которые перемещаются между слоями, могут представлять собой базовые структуры или простые объекты передачи данных, причем эти данные являются лишь аргументами для вызовов функций. Во избежание нарушения правила зависимости не следует передавать сущности или записи базы данных.
Выводы
Не существует архитектуры, которая была бы «серебряной пулей» и могла бы решить все проблемы. И это не «Чистая архитектура», которая пришла за этим.
После создания основы приложения, чистая архитектура помогает поддерживать и развивать приложение без необходимости больших затрат (физических ресурсов или времени). Этому способствует тот факт, что его слои независимы, а также постоянное использование шаблонов проекта, благодаря чему изменения определенной части системы, как правило, не мешают функционированию остальной части приложения.
С другой стороны, для работы над системой необходима более опытная команда разработчиков. Знание паттернов проектирования необходимо для поддержания и структурирования программного обеспечения. Кроме того, чтобы увидеть первые результаты, требуется больше времени, чем при простом применении MVP, и важно иметь тесную связь с клиентом, чтобы сделать очевидными будущие преимущества.
Наконец, делается вывод, что для приложений, которые имеют тенденцию расти и оставаться в течение многих лет, подход Clean Architecture является хорошим решением. Однако для простых систем, которые не эволюционируют, такая архитектура может не стоить усилий, и разумнее будет обратиться к более простым архитектурным паттернам.
Ссылки
- СОММЕРВИЛЛ, Ян. Программная инженерия. 9. изд. Харлоу, Англия: Addison-Wesley, 2010. ISBN 978-0-13-703515-1.
- Басс, Лен; КЛЕМЕНТС, Пол; КАЗМАН, Рик. Архитектура программного обеспечения на практике. 3rd. ed. [S.l.]: Addison-Wesley Professional, 2012. ISBN 0321815734.
- MARTIN, Robert C. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. 1-е изд. США: Prentice Hall Press, 2017. ISBN 0134494164.