Clojure @ Taiwan

51 readers
1 users here now

This is the new version of discussion group, used to replace the exising Clojure TW facebook group.

founded 2 weeks ago
MODERATORS
1
 
 

先講結論:

  • 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 核心哲學差異所在
2
 
 

我最近又在自找麻煩,把 Conjure 的一些應用技研究清楚。

比方說,有一個問題,我就覺得很討厭。

假如我有一個變數 a ,它是複雜巢狀的 edn ,但是沒有格式化,我該如何讓它格式化?

我當然可以用 pprint 。結果我用了 pprint 在 Conjure 裡一跑之後,就變成了:

; (out) {:request
; (out)  {:id "req_4G0EF3GLB3jqRG",
; (out)   :idempotency_key "1ed6791e-0cd7-4116-ae47-fa3869188f8f"},
; (out)  :type "payment_intent.created",
; (out)  :created 1745399047,
; (out)  :pending_webhooks 2,

全部給我自動加上 ; (out) 。 會有這個現象是因為Conjure 遇到列印到 stdout 的時候,就會自動加上 ; (out)

看似如此簡單的問題,正確的解法是這樣子:

  1. (tap> variable_a)
  2. <localleader> vt

這樣子就搞定了,因為 Conjure 的 <localleader> vt 就有自帶 pretty print 。