更清晰的MVC分层架构

这两天在网上粗浅的看了一下领域驱动设计DDD，这是一种经典的面向对象建模方法论，感觉与传统的开发模式有所差别，所以记录一下我的感受。

传统MVC三层架构

通常，我们习惯的业务建模方式是围绕数据表的，先根据业务需要设计数据库，再完成业务流程的开发。

在实现层面采用MVC分层框架，业务数据在3个层级之间流动（数据的流动性本质）。

虽然采用了MVC分层设计，但是在业务流程实现上仍旧是面向过程式，通常遵循这样的开发模式：取数据 -> 处理数据 -> 存储数据，是一种以数据为中心的过程式思想。

大家可以思考一下，你是不是也是这样开发业务的？

领域驱动设计（DDD）

该理论提出了一种新的分层模式，核心是强调面向对象。

interfaces是表现层，仍旧负责数据渲染，比如渲染页面，渲染json等等。

domain是领域层，是指具体的某一类实体与操作的类封装，比如订单与订单相关的操作。

application是应用层，组装多个domain，组成一个具体的业务流程，比如交易下单流程，可能需要调用订单、用户、反作弊等等domain。

对于订单来说，我们传统MVC通常只把它当做数据库记录，是一个”贫血模型”，里面只有订单的各个属性列，通过调用model层从数据库获取。同时，我们会写一个service层，封装对订单记录的业务操作方法，即过程式的面向数据的开发模式。

而DDD则不同，它强调订单是一类实体，具体某一条订单则对应一个订单对象。订单对象具有自己的业务处理方法，数据和方法是封装在一起的。

此时，如果创建订单需要获取用户信息，那么就需要application层来做组装：先获取用户对象，再调用订单对象的方法传入用户对象来完成下单的一个流程。

application就是来做具体业务流程的一层，进行多个domain的组装。

MVC与DDD的结合

没有银弹，多参考不同的思想，目标是如何优化业务设计与定制高效的开发规范。

我感觉DDD本质就是让属于不同领域的功能内聚，然后在应用层组装不同领域的功能即可。

而反观我们面向数据的思考方式，很容易做出这样的事情：为了实现一个跨领域的业务流程，直接将多种不同领域的业务逻辑实现在一起，即把分属于不同领域的逻辑一股脑的丢在应用逻辑层实现，导致了设计越来越混乱，复用性越来越低。

其实我们也不必完全参考DDD直接改造成面向对象的领域设计，毕竟团队擅长的建模方式仍旧是围绕数据的，而不是围绕领域对象的。

我们完全可以借助DDD来优化MVC分层设计，也就是以领域的眼光来优化MVC的使用。

之前在百度的时候，公司推广PHP Yaf框架的开发规范就提到很重要的一点，即遵循如下的分层设计：

view

controller

page

service

model

结合DDD，我们来重新设计一下每一层要做的事情：

model：特定领域数据的数据读写，比如 订单领域：

一般来说，订单分为主表和扩展表，两张表完整表达了订单业务，所以我会把它俩作为一个model实现。

service：该层与model层一一对应，说白了将model视作领域的数据部分（纯数据），service视作领域的方法部分，共同组成了类似DDD中的实体，只不过我们仍旧是面向数据和过程的实现。

page：与DDD的application层对应，组装多个service构成业务流程，向controller返回结果。

controller：解析请求，组装参数，调用page完成业务流程，将page返回值进一步加工成view需要的具体样子。

view：直接渲染html或者Json等，不应该包含其他的数据处理逻辑。

总结我的想法，service+model应该配对出现，page组装多个service完成业务流程，controller只是page与view之间的协调者（不应该有任何业务逻辑），

另外，service+model应该按领域思想划分，而不是按数据表划分，这样可以解决大多数的联表需求。

对于事务需求，应该在application层控制事务开关，依旧组装多个service完成事务内操作，保证不同领域的边界清晰。

注：关注作者微信公众号，了解更多分布式架构、微服务、netty、MySQL、spring、、性能优化、等知识点。

公众号：《 Java大蜗牛 》