好的分层能让应用内各模块的耦合度降到最低,耦合度越低就意味着程序的可维护性就越高。

所以我们 必须 将应用合理的进行分层。每一层的职责 必须 清晰,并且只向下依赖,高层可以依赖底层,但是底层 绝不 反过来依赖高层。

通过 领域模型 的概念及多数项目的经验,我们一般会将项目分层如下

路由层 (Router)

对外Api发布,Api版本控制。

中间件层(Middleware)

如果要实现鉴权、限流、过滤等等操作, 必须 在中间件实现,同时 绝不 在中间件中实现任何业务逻辑或者输出转换。

控制器层(Controller)

对于所有的输入校验和输出格式化你 必须 都放在控制器层实现,同时 绝不 在控制器中做任何业务逻辑处理。

服务层(Service)

必须 将所有的业务流程都放在服务层处理,服务层仅仅只处理业务流程,绝不 直接在服务层操作数据变更与查询。

数据仓储层(Repository)

所有的数据持久化与查询等操作都 可以 放在仓储层,同时 绝不 在仓储层做任何与业务逻辑相关的处理。(可选择是否抽象)

可以选择使用Model代替这一层, 两者职责与用途不一样,仅仅只在业务复杂度中可合适的选择。

基础层(Foundation)

基础层 应该 提供所有与业务流程、数据无关的接口(类),包括但不限于(发送短信,请求第三方接口,加解密算法,各类SDK)。

每一层都 应该 提供良好的抽象(Interface Or Abstract),要杜绝一切互相依赖,交叉依赖。

良好的抽象有助于进行单元测试从而提高代码健壮性。(无法被单元测试的代码就是无法被维护的)

ps: 其实这些分层结构是在 领域模型 的基础上去建立的, 如果有感兴趣的同学可以去百度一下. 也很期待大家一起来和我分享各自的见解.

若有收获,就点个赞吧

说点什么吧...