Полагаться на абстракции, а не на конкреции

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

Абстракция лежит в основе архитектуры программного обеспечения. Отделение what (что) от how (как), позволяет нам сосредоточиться на основной бизнес-проблеме, которую мы пытаемся решить, не теряясь в деталях конкретной реализации.

Абстракция

Следует полагаться на абстракции, а не на конкреции.
-- Принцип инверсии зависимостей

Конкреция - это когда мы полагаемся на имплементации, а не абстракции. Рассмотрим следующее приложение, которое предоставляет REST API для получения статьи блога из базы данных SQL:

(ns app.db
  (:require [next.jdbc.sql :as sql]))

(defn get-article-by-id
  "`data-source`: javax.sql.DataSource, `id`: article id"
  [data-source id]
  (sql/get-by-id data-source :article id))

(ns app.server
  (:require [app.db :as db]
            [reitit.ring :as ring]))

(defn get-article [data-source request]
  (let [id (get-in request [:path-params :id])
        article (db/get-article-by-id data-source id)]
    {:status 200
     :body article}))

(defn router [data-source]
  (ring/router
    [["/api/article/:id" {:get {:parameters {:path {:id int?}}}
                          :handler #(get-article data-source %)}]]))

(ns app.system
  (:require [app.server :as server]
            [next.jdbc :as jdbc]))

(defn init [db-spec]
  (let [data-source (jdbc/get-datasource db-spec) ;; javax.sql.DataSource
        router      (server/router data-source)] ;; reitit.core/Router
    ...))

В примере get-article связана с имплементацией get-article-by-id; маршрутизатор связан с get-article. В результате возникает эффект пульсации, который требует, чтобы маршрутизатор и обработчик знали о data-source, но единственная функция, которой нужно знать о data-source, — это get-article-by-id. Нам нужна действующая база данных SQL для тестирования текущей реализации маршрутизации.

Мы можем инвертировать зависимости, используя абстракцию. Если мы используем ту же сигнатуру, что и db/get-article-by-id, но удалим data-source, у нас останется функция, которая принимает id и возвращает article:

(fn get-article-by-id [id]
  article)

Мы можем настроить имплементацию нашей абстракции, используя функции высшего порядка:

(fn [id]
  (db/get-article-by-id data-source id))

(partial db/get-article-by-id data-source)

#(db/get-article-by-id data-source %)

Теперь мы можем передать функцию в server/get-article, куда ранее мы передали data-source, в результате чего получим чистую функцию:

(defn get-article
 "`get-article-by-id`: (fn [id] article)"
 [get-article-by-id request]
  (let [id (get-in request [:path-params :id])
        article (get-article-by-id id)]
    {:status 200
     :body article}))

Действуя аналогичным образом, мы можем удалить первый параметр get-article, чтобы сформировать нашу следующую абстракцию — обработчик запроса:

(fn handler [request]
  response)

#(server/get-article get-article-by-id %)

Последнее изменение необходимо внести в маршрутизатор; нам нужен способ передачи обработчика. В нашем примере показан один маршрут, но на практике, скорее всего, их будет много; мы можем использовать функцию, которая принимает ключ route и возвращает обработчик:

(fn route->handler [route]
  (fn handler [request]
    response))

Мы можем реализовать route->handler с помощью карты:

{:get-article #(server/get-article get-article-by-id %)}

Теперь мы разделили маршрутизатор и обработчик и устранили зависимость от data-source:

(ns app.server
  (:require [reitit.ring :as ring]))

(defn get-article
 "`get-article-by-id`: (fn [id] article)"
 [get-article-by-id request]
  (let [id (get-in request [:path-params :id])
        article (get-article-by-id id)]
    {:status 200
     :body article}))

(defn router
  "`route->handler`: (fn [route] (fn [request] response))"
  [route->handler]
  (ring/router [["/api/article/:id" {:get {:parameters {:path {:id int?}}}
                                     :handler (route->handler :get-article)}]]))

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

Мы можем использовать вместо get-article-by-id любую функцию с такой же сигнатурой без каких-либо изменений в коде app.server. Это может быть стаб/мок во время тестирования, обертка, добавляющая мониторинг/логирование/кэширование, или альтернативная реализация, которая получает статью из другой базы данных или внешнего источника.

Маршрутизатор имеет единственную обязанность: направить входящий запрос в обработчик. Обработчик также несет единственную ответственность: преобразование входящего запроса во внутренний вызов, где выполняется действие.

Протоколы

Протокол — это еще одна форма абстракции, которую мы можем использовать для разделения модулей. Такой подход в большей степени объектно-ориентированный, чем функциональный, но протоколы могут быть полезны, когда мы хотим получить более формальную абстракцию, или когда имеет смысл сформировать целостный набор моделей поведения. В предыдущем примере мы использовали единственную функцию для абстракции при извлечении статьи; в качестве альтернативы можно использовать паттерн репозитория, популярный в Domain Driven Design (Предметно-ориентированное проектирование):

(ns app.article-repository)

(defprotocol ArticleRepository
  (create [_ article])
  (get-by-id [_ id])
  (publish [_ id])
  (archive [_ id])
  (update-title [_ id title]))

(ns app.db
  (:require [app.article-repository :refer [ArticleRepository]]
            [next.jdbc.sql :as sql]))

(defrecord SqlArticleRepository [data-source]
  ArticleRepository
  (get-by-id [_ id]
    (sql/get-by-id data-source :article id))
  ...)

(ns app.server
  (:require [reitit.ring :as ring]
            [app.article-repository :as article-repository]))

(defn get-article [article-repository request]
  (let [id (get-in request [:path-params :id])
        article (article-repository/get-by-id article-repository id)]
    {:status 200
     :body article}))

Интерфейс в этом примере является более формальным, в том смысле, что мы запрашиваем пространство имен хранилища и ссылаемся на него напрямую, что отличается от первоначального использования ссылки на функцию, определенную через defn, поскольку мы ссылаемся на абстракцию, а не на протокол, определенный в app.db.

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

Композиция

Мы достигли развязки путем введения абстракций, следующим шагом будет объединение наших функций в систему. Для начала создается data-source и используется анонимная функция для обертывания db/get-article-by-id, в результате чего получается функция (fn [id] article). get-article-handler создается таким же образом, в результате чего получается функция (fn [request] response), которая помещается внутрь карты для построения абстракции route->handler:

(ns app.system
  (:require [app.db :as db]
            [app.server :as server]
            [next.jdbc :as jdbc]))

(defn init [db-spec]
  (let [data-source         (jdbc/get-datasource db-spec)               ;; javax.sql.DataSource
        get-article-by-id   #(db/get-article-by-id data-source %)       ;; (fn [id] article)
        get-article-handler #(server/get-article get-article-by-id %)   ;; (fn [request] response)
        route->handler      {:get-article get-article-handler}          ;; (fn [route] (fn [request] response))
        router              (server/router route->handler)]             ;; reitit.core/Router
    ...))

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

Составление больших систем может быть сложной задачей. Процессы должны запускаться и останавливаться в определенном порядке, а граф зависимостей может получиться большим, если следовать принципу инверсии зависимостей. Мы часто обращаемся к таким фреймворкам, как Component или Integrant, для помощи в построении больших систем, на момент написания статьи Integrant является рекомендуемым вариантом на нашем Clojure Radar.

Код для построения системы с помощью Integrant похож на код, который мы определили в привязке let:

(defmethod ig/init-key ::get-article-by-id [_ {:keys [data-source]}]
  #(db/get-article-by-id data-source %))

(defmethod ig/init-key ::get-article-handler [_ {:keys [get-article-by-id]}]
  #(server/get-article get-article-by-id %))

(defmethod ig/init-key ::router [_ {:keys [route->handler]}]
  (server/router route->handler))

С системой, объявленной в карте:

{::data-source {:db-spec db-spec}
 ::get-article-by-id {:data-source (ig/ref ::data-source)}
 ::get-article-handler {:get-article-by-id (ig/ref ::get-article-by-id)}
 ::router {:route->handler {:get-article (ig/ref ::get-article-handler)}}}

По мере роста системы мы можем разделить ее на целостные модули, с картами, создаваемыми для каждого из них, а затем смердженные в более крупные системы. Мы можем использовать ig/pre-init-spec чтобы убедиться, что зависимости соответствуют ожиданиям:

(s/def ::data-source #(instance? javax.sql.DataSource %))

(defmethod ig/pre-init-spec ::get-article-by-id [_]
  (s/keys :req-un [::data-source]))

Здесь хорошо работают протоколы; мы можем валидировать их с помощью satisfies? и отлавливать проблемы с подключением при инициализации системы:

(s/def ::article-repository #(satisfies? ArticleRepository %))

(defmethod ig/pre-init-spec ::get-article-handler [_]
  (s/keys ::req-un [::article-repository]))

(defmethod ig/init-key ::get-article-handler [_ {:keys [article-repository]}]
  #(server/get-article article-repository %))

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

Стабильность

Зависимости должны быть направлены в сторону устойчивости.
-- Принцип стабильных зависимостей

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

В нашем примере база данных является непостоянным компонентом, что, в свою очередь, делает нестабильными пространства имен сервера и системы. Красные стрелки на диаграмме показывают компоненты, которые являются нестабильными из-за своих зависимостей:

Благодаря введенным абстракциям пространство имен server больше не зависит от волатильной зависимости; теперь это стабильный компонент.

Альтернативная реализация с протоколом ArticleRepository имеет дополнительные стрелки, показанные светло-зеленым цветом, которые указывают на него:

Пример: Приложение для управления проектами

На таком тривиальном примере преимущества развязки, возможно, не столь очевидны. Рассмотрим более сложный пример приложения для управления проектами, в котором пользователи могут создавать проекты и управлять тикетами в рамках проекта, с отправкой уведомлений при изменении статуса тикета:

Управляемые сервисы являются нестабильными компонентами, и их имплементация требуется непосредственно в ходе проекта, что приводит к созданию тесно связанной системы, в которой все является волатильным. Хотя некоторые компоненты в системе должны быть изменчивыми, крайне нежелательно, чтобы полностью все в ней было волатильным.

Многослойные архитектуры

Hexagonal (гексагональная) архитектура, Onion (луковичная) архитектура, Clean (чистая) архитектура и Functional Core(функциональное ядро), Imperative Shell (императивная оболочка) — все они помещают высокоуровневую бизнес-логику в ядро приложения и используют слои для того, чтобы низкоуровневые детали, такие как база данных и транспортные протоколы, оставались на периферии.

Мы можем разделить приложение для управления проектами на слои, отделив основной домен от специфики реализации. В результате получается слой domain, который зависит только от абстракций и не знает о внешних зависимостях; обратите внимание, что стрелки никогда не направлены от домена к слою инфраструктуры. Абстракции реализуются в слое infrastructure и соединяются вместе, образуя систему:

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

Заключение

Осознайте, что когда вы упрощаете что-то, зачастую вы в конечном итоге получаете гораздо больше. Упрощение - не означает подсчитать количество. Я бы предпочел иметь больше вещей, висящих красиво, ровно, не скрученных вместе, чем всего пару вещей, завязанных в узел. И самое прекрасное в том, чтобы разделить их, - тогда у вас будет гораздо больше возможностей изменить их, а именно в этом, как мне кажется, и заключается главное преимущество.
-- Рич Хикки (Rich Hickey) Простое сделать легким

Строгое разделение "что" и "как" — это ключ к тому, чтобы сделать "как" чьей-то проблемой. Если вы сделали это действительно хорошо, то можете переложить работу над "как" на кого-то другого. Вы можете сказать: "Механизм базы данных — выясни, как сделать эту вещь" или " Логическая схема — выясни, как найти это". Мне не нужно вникать.
-- Рич Хикки (Rich Hickey) Простое сделать легким

Абстракции очень важны, если мы стремимся разрабатывать большие системы, которые будут простыми и удобными для обслуживания в долгосрочной перспективе. Взгляните на свою собственную кодовую базу и определите, где вы привязаны к определенной реализации, нарисуйте граф и посмотрите, куда указывают все стрелки, найдите нестабильные компоненты и рассмотрите возможность внедрения абстракций для разделения модулей и отделения what от how.

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

Приглашаем всех желающих на открытый урок «Написание игры "Game Of Life" на Clojure». На этом уроке вы увидите, как классическая задача computer science — Game of Live, может быть реализована на Clojure. Также мы обсудим разные способы визуализации работы алгоритма, как представить состояние игры с помощью персистентных структур данных и как вести разработку интерактивно через REPL. Записаться на урок можно на странице курса "Clojure Developer".

Абстрактный Clojure