软件分层设计与常见业务对象

Spring mvc 做久了其实挺无聊的，一直在业务层自旋，不大好突破到新的境界，这其实和业务规模和用户数量以及应用场景都有关系，当然还要考虑上线求稳的心理，ok 话回正题，在spring mvc的时代整个项目作为一个整体放在容器中对外提供服务。

这个是读过下方参考文章的模块划分图 之后产生的思考，其实读完这个之后也触发了我之前很多关于这些的想法，写出来算是自己沉淀下，不全后续再有灵感可以在补充。

 

原图如下：

 

经典的三层架构：

1. 基础层：dao, 帮助类，IO读写，资源加载等一些基础设施，他们作为整个系统最基础的模块可以组合成业务层和服务层

2.业务层和服务层：典型的就是 service,这里承载更多的是业务的实现，资源的组合调度，事务实现，等等，这里是整个系统最核心的地方，下面整合底层dao以及事务，根据业务和场景灵活的把业务逻辑使用底层的基础单元拼接组合起来，上面为表现层提供具体的业务处理逻辑

3.表现层：接受外部的请求，并把调用对应的service操作具体业务，把最终结果反馈给调用者或是用户

四层架构，在基础层基础之上还可以在分出一层：领域层，基础层还是提供基本的数据操作和IO与网络操作，不过领域层对基础层再来一次封装和整合，目的也是方便整合底层资源方便service层调用，简化业务层和基础层的复杂依赖

 

静态业务对象：

ViewObject : VO 界面展示用到的数据对象

DomainObject: DO  领域层对象，一般可以简约的理解为java bean对象，从业务中抽取的基本模型类

BussinessObject: BO 业务对象一般也在service业务层，如果DO不能完全表达，可以使用BO获取更多信息的表达，并且还可以封装重用DO中的实体信息

PersistantObject: PO 持久存储对象，一般作用于dao层，和数据库实体对应

DataTransferObject : DTO 数据传递对象，用于封装参数，数据中转会，重构过程方法列表会用到

 

动态处理对象：

Controller 控制器, Manager 管理类, Service 服务类, Repository, DAO 数据源, Client 客户端,  Dispather 转发器, Handler 处理器, Interceptor 拦截器

Helper,Utils,Tools 帮助类，Reformer(转换类)，Ddcorator(装饰器)，Builder(建造者)，Transformer(转换器), Parser(解释器)

 

动态的配置文件与属性：

一些经常用到的开关和阈值一定要写在配置文件中，或有配置中心可以下发，不要在程序中写死，而且要有对相应的刷新机制api接口，调用后强制刷新配置参数

常用的比如：

• 活动的开始结束日期
• 业务中的最大值，限制值等阈值
• 外界的URI: 文件上传地址，静态资源位置，等等
• .....等等一切可以借鉴Ioc理念抽取出来的配置变量

 

其实如果在往下还可以在细分：对外接口层, 接入层, 持久层... 大的框架会描述一个思考的方向，根据业务和场景的不同可能会有不同的要求，项目不同阶段也会面临变化，这及时软件给人带来困惑的地方，也是让人欣喜的地方，到底什么样的架构才是好的架构，随着时间和迭代的前进你会发现不同时间都有不同的考虑和考量，任何时候都没有完美的方案，可能会因为排期和deanline的压力或是行政绩效的压力选择一些妥协的方案或是自己懒惰没有做出相对较好的方案，但是你会发现永远都没法完美，就像极限的概念你可以无限接近但就是无法达到....

 

参考文章：http://ifeve.com/am-hierarchy/