設計資料庫模型有幾分像設計應用程式的物件模型，像到有時你會懷疑：同時維護兩者，是否違反了「不要重複自己」（Don’t Repeat Yourself, DRY）原則？

應用程式狀態與資料庫模型的根本差異#

兩者其實各司其職：

• 應用程式實作的是工作流程（workflow）、使用者故事（user story）、與系統互動的方式——展示層、輸入系統、事件收集 API 等動態且面向使用者的活動。
• 資料庫模型則隨時確保整個世界的一致視圖：讓每個參與者只需專注自己的業務，並彼此隔離保護，使整體世界持續保持合理。

因此，應用程式的物件模型最好專屬於一組使用者故事，只涵蓋整個產品中一塊紮實的部分。

以市集（marketplace）應用為例：

• 使用者刊登系統負責向使用者收集資訊並呈現給其他使用者。這部分的物件模型可能需要定價資訊，但完全不需要知道客戶的開票系統。
• 資料庫模型則必須確保每筆付費的使用者行為都被正確入帳，並開立發票給正確的對象——不論是內部記帳或寄給客戶。開票通常還要實作各國 VAT 規則，依商品種類、買方是公司或個人而異。

為整個應用程式維護單一物件模型，容易導向單體式（monolith）設計、降低模組化程度，進而拖慢開發速度、加速技術債累積。

最佳實務是把「使用者工作流程」與「系統性一致性」分開設計——交易（transaction）正是為了實作後者而發明的機制。RDBMS 本來就該是應用程式設計的一部分，隨時確保世界的一致。

資料庫建模與物件建模是非常不同的兩件事：一邊是持續演化世界的可靠快照，另一邊是暫時性的、進行中的工作流程。