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

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

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

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