對領域驅動設計DDD（Domain-Driven Design）的了解

軟體工程出現以來，人們一直在尋找一種簡潔的系統組織方式及互動方式。

傳統的系統設計是指令式互動，系統對外提供了哪些操作指令，即系統對外提供了哪些接口。系統的設計是圍繞着接口進行的，對接口的實作就是對這些指令的實作，使用者通過接口來修改系統的狀态（包括系統中存儲的資料）。

對于非程式設計人員來說，隻能看到系統所提供的接口，“看不到”系統内部的實作。系統分析和設計是分開的，導緻需求和成品非常容易出現偏差，兩者相對獨立，還會導緻溝通困難。DDD 則打破了這種隔閡，領域模型概念統一了分析和設計程式設計，使得軟體能夠更靈活快速跟随需求變化。

DDD提供了一種很好的現實世界對系統的投影方式，DDD中的領域對象就對應着現實世界的人。DDD的出現實際上減輕了程式設計人員的負擔，它讓非程式設計人員（産品、測試）也可以很友善的了解系統的架構，可以讓更多的人參與到系統的設計工作當中來，甚至産品經理都可以直接進行初版的系統設計，但是它增加了系統内的耦合（領域對象之間的耦合肯定高于Service之間的耦合）。

比如，要做一個抽獎系統，那麼系統裡就需要這些“人”：

• 記錄抽獎活動基礎資訊的從業人員
• 抽獎的從業人員
• 發放獎品的從業人員
• 中獎播報的從業人員

如果在設計過程中發現某個“人”的職責太多，還可以對這個“人”進行拆分，如果可以從“記錄抽獎活動基礎資訊的從業人員”中拆出一個“記錄抽獎活動獎品基礎資訊的從業人員”。