如何做好应用架构分层和模块化?

时间:2022-06-21 08:24:27

如何做好应用架构分层和模块化?

上次关于如何编写代码的文章里面提到了应用的模块化分层,这篇文章就来聊聊这个事情。

没有顶层设计、模块划分的应用就像一团打结的毛线,代码分支可能会跳来跳来,没有边界。很难理清楚内部的业务逻辑,更糟糕的是随着需求的堆积,日积月累更难理清楚内部的模块划分,所以从一开始就应该定好系统的模块,确定好边界之后才知道每一部分往哪里放。

每次实现一个新需求内心都有一个层次树,大概会在哪个模块加什么东西,传统的MVC 模型在web 应用流行了很久,也很容易理解,下面我基于之前实现的一个系统做了些修剪和设计,形成了一个比较通用的分层架构

如下图:后面分别讲解每一个模块的职责。

如何做好应用架构分层和模块化?

应用分层和模块化

controller

控制器层大家应该都不陌生,写过web应用的都知道,这个是http 请求的入口,controller 负责接受web请求HttpRequest, 返回HttpResponse。

biz-service-api

业务服务层的接口定义,一般简单的应用不需要区分 biz-service 和 core-service,但是如果业务复杂度比较高,最佳实践是把service 拆二层,biz-service 负责业务逻辑,业务逻辑是繁杂多样的,随时会变,而那些具有通用性的基础能力、有时候也叫平台能力放到core-service 里面,比如很多业务都需要支付能力,支付的服务就可以作为平台能力放在core-service 提供给biz-service使用。biz-service 使用core-service的能力,在阿里内部系统,非常重视core-service,如果系统拆分成域来看,core-service 可以理解成中台,biz-service 是前台,大中台小前台战略除了在组织结构上,也可以在应用内体现,一般都是把中台能力做强,前台能力负责灵活、高效满足业务需求。

facade

门面接口,和设计模式里面的门面有点像,facade 模块只定义接口,具体实现放在biz-service-impl 模块。facade 一般是提供给外部系统的,打成jar 包,人家依赖你,只需要知道接口定义的出入参,具体实现他不需要关心。你的facade 服务发布成rpc provider,为上游提供服务。

其实有很多系统会把facade 层放在core-service 层下面,因为认为facade 提供的服务都是rpc 服务,一般只在内部发布,但是我觉得放在和controller 一层逻辑比较顺,也比较清晰,当然也是因为调用我controller 的也是内部系统,所以我一视同仁。

biz-service-impl

业务逻辑实现,实现facade 接口和 biz-service-api。

core-service-api

核心能力服务api定义。核心原子能力的定义,比如支付能力、模型运行能力、通用对象定位能力、安全。

core-domain

这里承载核心领域,最重要的模型都放在这个模块,有的架构设计这里除了模型,还会防model-service,但是我还是觉得模型更多是数据的概念,模型的操作应该是自包含的,也就是模型的操作只依赖自己的数据,可以直接在模型内部完成,如果需要多个模型参与的操作都应该交给core-service 来完成。算是DDD 领域驱动设计的折中,可理解性比规范有时候更重要,这方面的例子还很多,比如大型互联网公司的表设计就没有遵循数据库规范的范式,表join 都很少,单表冗余情况很多。

infrastructure

基础的比如数据库、缓存、消息队列、流程引擎、审批流、定时任务这种系统基础设施,还有第三方外部系统依赖都放在这一层。一般我的建议是每引入一个第三方服务或者组件,都定义service-api 和 serviceImpl,api做出通用性的,不依赖具体第三方的存在,这样比如接入了A 公司提供的流程引擎,发现不合适,不好用的时候api 这一层不用动,也不会影响到上层应用的服务,而且还可以非常好的支持SPI机制,方便切流到新服务提供者上去。

上面有的是按照层的概念说的,有的是按照模块来说的。这篇文章我自己觉得挺有价值的,工程上的一些最佳实践,希望对大家在做应用架构设计的时候有帮助。

原文链接:https://mp.weixin.qq.com/s/-Ae2GnPwWFnpKFtQTKOCKA