产生背景
业务复杂、需求不断、人员变更快、问题多等诸多原因导致项目分层混乱，服务技术是基于PaaS开发的服务定义Jstorm Topo的一个分布式服务。
存在问题
- 服务初始化混乱，如有通过PostConstruct注解初始化，有通过Spout的open初始化，有通过Bolt的prepare方法初始化，有通过其他一些初始化方法初始化的；
- 服务没有按需初始化，例如Spout、Bolt需要的依赖数据是不一样的，分布式服务，需要根据业务需求按需初始化；
- 开发新需求时，很难决定类建在何处更合适，在扩展旧的需求时，经常需要稍等重构很多的代码，重复代码极其多；
- 缓存使用混乱，无法统计项目使用的堆内、堆外内存，且随意创建缓存，导致服务运行期间产生大量OOM；
- 设计模式意识淡薄，例如在写文件时，代码套用在一起，用if-else去分流逻辑，慢慢积累下来，项目硬编码极其多，往往在做新需求时才发现现有框架已不支持，导致需求完成时间骤增；
- 线程乱用，随意创建线程，运行期间导致线程数量暴增，在大容量下导致IO问题，为定位问题造成了很大的困难。
为什么需要好的分层设计
- 节省内存资源，按需初始化缓存，缩短服务初始化时间；
- 需求扩展时更得心应手，让新手书写功能时，知道如何更好去写代码；
- 更好的管理业务，不能一写需求牵一发而动全身；
- 好的分层设计，可以减少代码重复度，更好的减少硬编码；
- 好的分层设计，可以让开发人员更好的理解业务；
- 好的分层设计，可以让项目分工更加明确，可读性大大提升。
什么是好的分层设计
- 方便后续代码进行维护扩展；
- 分层的效果需要整个团队都能接受；
- 各个层职责边界清晰。
怎样做好分层设计
大部分项目分层在主体上是分为三层架构，秉持着”高内聚低耦合”的思想去设计项目的分层。横向切割，根据业务职责划分。划分的目的是规划软件系统的逻辑结构便于开发维护。要做到根据领域建模，模型之间隔离。
请求处理层（Controller层） VO
业务逻辑层（Service层） BO
数据持久层（Dao层） DO
请求处理层：三块能力 一个是通过模板引擎渲染； 二 是 对外提供的restful接口； 三 是对上游业务提供的RPC接口
数据持久层：承载了数据存储和访问的能力，它既与底层数据进行交换，又通过Proxy的代理和包装与远程服务数据进行联动。
业务逻辑层：职责是与数据持久层交互
但随着业务的发展，微服务的拆分，分布式服务架构的盛行，三层架构逐渐无法满足业务的需要。
分层中各数据模型的解释说明：
DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象
DTO（Data Transfer Object）：远程调用对象，RPC服务提供的领域模型，需保证序列化
BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象
VO（View Object）：显示层对象。通常是Web向模板渲染引擎层传输的对象
DAO（Data Access objects）：数据传输对象，Service或者Manager向外传输的对象
AO（Access objects）：应用对象。在Web层与Service层之间抽象的复用对模型，极为贴近展示层，复用度不高
细节分层
- 查询分层
- 枚举分层