## 业务举例 这是一个短信邮件平台模块，它在整个系统中有两个职责。 一、负责为其他模块提供短信邮件发送的远程调用接口； 二、有一个后台页面，可以让管理员自定义发送短信，并且可以浏览全部的发送记录。 ## 分层说明 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/)