这两天在网上粗浅的看了一下领域驱动设计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完成事务内操作，保证不同领域的边界清晰。
为了让学习变得轻松、高效，今天给大家免费分享一套阿里架构师传授的一套教学资源。帮助大家在成为架构师的道路上披荆斩棘。
这套视频课程详细讲解了（Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构）等这些成为架构师必备的内容！
而且还把框架需要用到的各种程序进行了打包，根据基础视频可以让你轻松搭建分布式框架环境，像在企业生产环境一样进行学习和实践。
