淺談領域驅動設計（DDD，Domain-Driven Design）

DDD 是一種軟體開發方法論
將業務邏輯擺在開發的核心
善於解決複雜且多變的業務需求
與之相對的是技術驅動設計和資料驅動設計

步驟：

技術驅動設計是以技術為出發點，先決定語言、框架等再去滿足業務邏輯
可能造成業務邏輯被壓縮，難以應對業務變化

資料驅動設計專注於資料表的結構規劃，重視的是如何儲存與搜尋資料
無法反映真實的業務運作流程

DDD 的一個差異是由前往後走。從貼近現實世界的使用者與產業，到看不見的後端程式，再到更底層的資料庫。另一個差異是解耦。DDD 不用管軟體怎麼實作，軟體也不用關心資料庫怎麼實作。

而傳統的資料處理人員是由資料庫出發，所以軟體只能被迫按照資料庫去走。可怕的是資料表包含各種產業知識、業務邏輯。所以一旦業務需求有一點調整，往往就是加開欄位、多套 SQL、使用 Stored Procedure。系統也跟著疊床架屋，最後不可維護。

現今的資料庫越來越強大，除非是極大的資料量，否則不太會出現效能問題
而各種框架的成熟如 SpringBoot 讓技術門檻降低許多，也不再是核心問題
因此剩下要攻克的就是複雜的業務邏輯

不能這麼說，軟體世界中沒有一招打天下的
如果業務邏輯不複雜，用基本的 CRUD 技術就能處理，當然不需要 DDD 出馬
如果資料量龐大，對性能有極高要求，當然需要在資料庫中額外設計

DDD 中的 Entity 是指 Data Model 或 E-R Model
資料庫中的 Entity 是指 Table Schema

參考資料：