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