基于Spring的web服务端逻辑代码层次及对应职责的一点想法

引子

根据Robert C.Martin在《敏捷软件开发-原则、模式与实践》一书的观点，一个基本满足敏捷开发的代码应该符合以下5个原则：

SRP  单一职责原则
    就一个类而言，应该仅有一个引起它变化的原因。
OCP  开放一封闭原则
    软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。
LSP  Liskov替换原则
    子类型必须能够替换掉它们的基类型。
ISP  接口隔离原则
    不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。

DIP  依赖倒置原则
    抽象不应该依赖于细节。细节应该依赖于抽象。
但在现实中，由于各个各样的原因，系统中总会有这样那样不符合这5个原则的地方。

这样的代码维护起来就两个字： 累  乱。

一个理想的系统,代码层次应该是这样的:

 

较理想的代码层次和职责

 

层次	职责	允许的操作	不允许的操作
外部入口层(输入入边界)	接收外部请求,封装成代码内部可用数据	读取各种外部输入资源，如http请求，文件等	直接调用基础服务 包括直接调用dao，mc，mq等
接口服务层	校验请求数据的格式合法性,并调度各个业务服务，串联推动业务服务		无特殊情况，不直接调用基础服务层
业务服务层	进行一个和多个领域模型之间的业务的封装,	缓存各种独立在db外的信息 可配合工具类实现领域对象的重新封装
领域服务层	提供单个领域的各种操作,如增删改查。	缓存各种基于db的列表信息 可配合工具类实现领域对象的重新封装
基础服务层	提供基础的存储和外部服务依赖的	dao服务：可对应db行记录缓存领域对象	dao服务无特殊情况不缓存 领域对象的列表