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

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

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

每次实现一个新需求内心都有一个层次树，用架大概会在哪个模块加什么东西，构分传统的层和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机制，方便切流到新服务提供者上去。

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

最新评论