工具-領域邏輯組織模式

🎯 什麼情境該想到我

當你的業務邏輯「散落各處、service 層越來越肥、不知道邏輯該放哪」時。

⚙️ 怎麼用（依業務複雜度選）

1. Transaction Script（交易腳本）：一個動作＝一段程序式流程。簡單業務用它最直接，別過度設計。
2. Domain Model（領域模型）：把業務邏輯放進有行為的領域物件（充血模型），而非只有 getter/setter 的貧血物件 + 肥 service。複雜、多變的業務用它才管得住（呼應 領域驅動設計）。
3. Table Module：以「一張表對應一個類別」組織邏輯，介於兩者之間。

判斷：業務越複雜、規則越多變 → 越該用 Domain Model；越簡單 → 越該用 Transaction Script。 別為簡單 CRUD 硬套領域模型。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 「貧血模型 + 肥 service」在複雜業務下會失控；但簡單 CRUD 硬做充血模型也是過度工程。按複雜度選。

🔗 相關工具

• 工具-物件關聯映射模式 —— 配套決策，選了領域模型就得配較重的 ORM，選了交易腳本用閘道就夠
• 工具-實體值物件與聚合 —— DDD 版的細化，走領域模型路線時用它決定物件怎麼切
• 工具-管理複雜度 —— 選型準則，業務複雜度不高時硬上領域模型只是徒增複雜