更清晰的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大蜗牛 》