## 業務舉例 這是一個短信郵件平臺模塊，它在整個系統中有兩個職責。 一、負責為其他模塊提供短信郵件發送的遠程調用接口； 二、有一個后臺頁面，可以讓管理員自定義發送短信，并且可以瀏覽全部的發送記錄。 ## 分層說明 1. \[Controller\] DTO、輸入輸出，控制調度 2. \[Validate\] \[高內聚，可復用\] 對每個業務場景提交的參數進行數據驗證 (只負責Client傳遞的數據) 3. \[Service\] 業務流程處理、Model聚合，Transaction Script 4. \[Model\] \[高內聚，可復用\] 數據持久化操作、模型相關功能 5. \[Config\] 配置信息 ## 反例：MVC高于業務 ``` application [config] Common Mail Sms (more...) [model] Base Mail Sms (more...) [service] Base Mail Sms (more...) [validate] Base Mail Sms (more...) [controller] Admin Mail Sms (more...) ``` 這樣的設計會導致同層逐漸變得臃腫，使項目僵化。如打開Controller層一看就是好幾十個，只是把代碼塊移了一個地方而已，一看源碼還是頭疼新人接手找都找不到。 ## 例子：業務分層包含MVC >規范的高內聚結構，應遵循業務 > mvc 的原則，可以知道我們的項目龐大但卻有條理 ~~~ application [common] [config] app.php ... [model] base.php mail.php sms.php ... [mail] [config][非必須] config.php ... [service] mailService.php smsService.php [validate] mailValidate.php smsValidate.php [controller] mailController.php smsController.php [admin] .... ~~~ 在實際開發過程中對業務模塊的界限劃分其實是很容易混淆的，此處mail模塊的劃分粒度是很大的，具體如何劃分關聯性很強的業務其實沒有一個絕對的標準，如果你的用例很復雜或用例大于>30，那么建議使用DDD領域驅動設計進行合理拆分。 原文地址：[https://www.cnkirito.moe/Re-DDD/](https://www.cnkirito.moe/Re-DDD/)