原文参见：代码分层的设计之道
在复习设计模式的知识点，首先复习的是单一职责原则。这个原则本身理解简单，实践却并不容易，需要在编码和架构设计的过程中，不仅对代码本身做的事了解，还需要对业务有总体了解，这样才知道怎么划分职责，服务化的过程中怎么拆分服务。
之前看过梁桂钊写过类似的东西，记不起来了，现在再去看看。
我的目标是：弄明白应该如何拆分类或者服务，有没有具体的最佳实践或者指导原则。
分层思想，将系统横向分割，根据业务职责划分，比如MVC。
view层不直接和model层交互，而是通过controller层。
model层专注于处理数据
view层专注于渲染数据
controller层专注于，转发view层对数据的请求，将model层的数据响应结果返回给view层渲染
传统MVC架构的问题在于，前后端职责耦合，降低了开发的效率。前端不能专注于渲染数据，后端不能专注于处理数据。
因为后端直接发送渲染后的视图给前端，前端在开发的时候可能需要搭建后端环境才能把环境跑起来。
比如使用基于servlet的模板技术jsp开发，开发的过程中，jsp需要依赖servlet容器才能展示效果。
首先需要解决的痛点是数据与视图分离，于是，view层纯粹的进行前端展示逻辑、样式编写，于是前端通过Ajax异步向后端controller请求数据，controller只发送json格式的数据给前端，不发送完整视图。
代码分层参考：
图片来源http://blog.720ui.com/2018/server_layer/#textlogo
数据持久层：专注于数据的查询和修改，只被业务逻辑层访问。
业务逻辑层 的职责是与数据持久层交互，对多个数据源的操作进行聚合，并且提供组合复用的能力。此外，它也是业务通用能力的处理层，其中还包括缓存方案、消息监听（MQ）、定时任务等等。此外，我们要将尽可能多的业务处理放在业务逻辑层，包括了参数校验、数据转换、异常处理等，而不是在 Controller 再去处理。
请求处理层：模板引擎返回整个页面、json数据、RPC调用、其他WebService调用。
项目结构：
图片来源http://blog.720ui.com/2018/server_layer/#textlogo
禁止跨层级调用
领域模型：
DO（Data Object）与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。
DTO（Data Transfer Object）是远程调用对象，它是 RPC 服务提供的领域模型。
DTO 一定要保证其序列化，实现 Serializable 接口，并显示提供 serialVersionUID，否则在反序列化时，如果 serialVersionUID 被修改，那么反序列化会失败。
DO 和 DTO 唯一的区别在于，一个是本地数据源的领域模型，一个是远程服务的序列化领域模型。
BO（Business Object），它是业务逻辑层封装业务逻辑的对象，一般情况下，它是聚合了多个数据源的复合对象。
VO（View Object） 通常是请求处理层传输的对象，它通过 Spring 框架的转换后，往往是一个 JSON 对象。
总结：
1、代码分层参考，可以结合自己的项目来分析
2、项目结构，可供参考
3、领域模型，在领域建模的时候可以参考