Clojure 组合根 - Code Recipes

设计模式 / 整洁架构模式

;; Composition root folds into one function that builds
;; the adapters and hands them to the use case: no
;; container, only arguments

;; Entity
(defn payable [order]
  (let [total (:total order)]
    (if (>= total 200)
      (- total (quot total 10))
      total)))

;; Gateway
(defprotocol Catalog
  (price [catalog sku]))

;; Repository: it numbers what it saves
(defprotocol Orders
  (save [orders order])
  (saved [orders]))

;; Output port
(defprotocol Report
  (say [report text]))

;; Use case: asks for its parts, never builds them
(defn place-order [catalog orders report]
  (fn [items]
    (if-let [sku (first (remove #(price catalog %)
                                (keys items)))]
      (say report (str "no " sku))
      (let [total (reduce + 0
                          (for [[sku qty] items]
                            (* (price catalog sku) qty)))
            order (save orders {:total total})]
        (say report (str "order " (:id order)
                         " for " (payable order)))))))

;; Adapters
(defrecord MemoryCatalog [prices]
Catalog
  (price [_ sku]
    (get prices sku)))

(defrecord MemoryOrders [rows]
Orders
  (save [_ order]
    (peek (swap! rows
                 (fn [kept]
                   (conj kept
                         (assoc order :id
                                (+ 1001 (count kept))))))))
  (saved [_]
    (count @rows)))

(def console-report
  (reify Report
    (say [_ text]
      (println text))))

(def silent-report
  (reify Report
    (say [_ _])))

;; Composition root: the only place that sees every
;; layer at once, and the only place that names an
;; adapter. The app it returns is a plain map
(defn shop-app [report]
  (let [orders (->MemoryOrders (atom []))]
    {:place (place-order
              (->MemoryCatalog {"pen" 30 "lamp" 190})
              orders
              report)
     :orders orders}))

(defn loud [] (shop-app console-report))
(defn quiet [] (shop-app silent-report))

;; Client code
(def app (loud))
((:place app) {"pen" 2 "lamp" 1})
((:place app) {"chair" 1})

;; A second root builds the same use case differently
(def night (quiet))
((:place night) {"lamp" 1})
(println "saved" (saved (:orders night)))
;; printed: order 1001 for 225
;;          no chair
;;          saved 1

A composition root is the only place where the layers are connected and the adapters are built; the rest of the application only asks for its parts.

问题。用例需要一个价格目录、一个订单存储，以及一种报告结果的途径。如果用例自己创建这些部件，它就会指明外层的适配器，并依赖于它们。测试也无法为它提供别的部件。如果程序的每个部分都自行构建自己的部件，就没有人能看清应用程序是如何连接起来的。

思路。组合根是唯一一个连接各层、构建适配器的地方。适配器是实现端口的外层代码，而端口是内层声明的接口。用例只通过端口索取自己的部件，从不自己构建它们。组合根同时了解每一层，这正是它的职责。其余所有代码都遵守依赖规则：内层代码从不了解外层代码。这不需要任何框架或容器：组合根就是程序启动处的普通代码。

如何阅读示例。用例索取三个端口：一个查询价格的网关、一个保存订单的仓库，以及一个用于报告的输出端口。外层为它们提供了适配器：内存中的目录和存储，一个会打印的报告，还有一个什么也不说的报告。示例把应用程序构建了两次。第一次构建中，报告会打印：客户端代码下了订单 1001，应付 225，又下了一个含未知商品的订单。第二次构建使用静默的报告，因此它的订单什么也不打印。只有已保存订单的数量表明它们确实被保存了。两次构建中的用例完全相同。

何时使用。每个应用程序都有一个组合根，位于它的启动处；测试可以有自己的小型组合根，使用假的适配器。没有端口的短脚本不需要组合根。

常见错误。在用例内部创建适配器，哪怕只有一次。这样用例就依赖于外层，组合根也不再能展示应用程序是如何连接起来的。