先講結論：

  • Clojure 的哲學不是反對架構，而是反對不必要的複雜與重抽象（over-abstraction）。
  • 《PEAA》雖出自 OO 世界，但它提供的「複雜系統常見問題的分類」仍然對理解大型應用程式的設計具有參考價值。

Clojure vs. PEAA 架構觀點對照表

主題 / 架構關注點 PEAA 傳統作法 Clojure 社群作法 / 思想 備註
Domain Logic 組織 Transaction Script / Domain Model / Table Module 純函數 + maps，無需複雜分層 接近 Transaction Script，但更 composable
資料模型與 ORM Active Record / Data Mapper next.jdbc / HoneySQL / raw SQL；避免 ORM 強調透明性與控制性
Service Layer 明確定義 Service Layer，封裝業務操作邏輯 命名空間中函數直接代表 service 無需額外「層」，只要邏輯清楚
DTO（資料轉換物件） DTO 是必要的封裝傳輸結構 map 本身即為資料；轉換靠函數實作 不封裝資料、讓轉換明確
Repository pattern 一層介面抽象資料來源（e.g., JPA repository） 直接使用 SQL/DSL；必要時以 protocol 封裝 避免過早抽象
Remote Facade 使用 RPC façade 抽象網路通訊 REST/HTTP handler + 資料直接輸出 保持資料透明，不抽象「行為」
物件導向封裝邏輯 封裝狀態與邏輯於物件中 分離資料（immutable maps）與邏輯（純函數） 關注點分離；更易測試與理解
狀態管理 對象內部維護 mutable 狀態 使用 immutable 資料結構，顯式傳遞狀態 更容易 debug 與回溯
分層架構（Layered Architecture） UI → Application → Domain → Data Source 依邏輯功能拆命名空間；非硬性分層 分層更彈性、依實際需求決定
策略心態 複雜可藉由模式控制 複雜性應避免；decoupling > pattern 核心哲學差異所在