好的分层能让应用内各模块的耦合度降到最低,耦合度越低就意味着程序的可维护性就越高。
所以我们 必须 将应用合理的进行分层。每一层的职责 必须 清晰,并且只向下依赖,高层可以依赖底层,但是底层 绝不 反过来依赖高层。
通过 领域模型 的概念及多数项目的经验,我们一般会将项目分层如下
路由层 (Router)
对外Api发布,Api版本控制。
中间件层(Middleware)
如果要实现鉴权、限流、过滤等等操作, 必须 在中间件实现,同时 绝不 在中间件中实现任何业务逻辑或者输出转换。
控制器层(Controller)
对于所有的输入校验和输出格式化你 必须 都放在控制器层实现,同时 绝不 在控制器中做任何业务逻辑处理。
服务层(Service)
你 必须 将所有的业务流程都放在服务层处理,服务层仅仅只处理业务流程,绝不 直接在服务层操作数据变更与查询。
数据仓储层(Repository)
所有的数据持久化与查询等操作都 可以 放在仓储层,同时 绝不 在仓储层做任何与业务逻辑相关的处理。(可选择是否抽象)
可以选择使用Model代替这一层, 两者职责与用途不一样,仅仅只在业务复杂度中可合适的选择。
基础层(Foundation)
基础层 应该 提供所有与业务流程、数据无关的接口(类),包括但不限于(发送短信,请求第三方接口,加解密算法,各类SDK)。
每一层都 应该 提供良好的抽象(Interface Or Abstract),要杜绝一切互相依赖,交叉依赖。
良好的抽象有助于进行单元测试从而提高代码健壮性。(无法被单元测试的代码就是无法被维护的)
ps: 其实这些分层结构是在 领域模型 的基础上去建立的, 如果有感兴趣的同学可以去百度一下. 也很期待大家一起来和我分享各自的见解.
若有收获,就点个赞吧