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

   上次关于如何编写代码的文章里面提到了应用的模块化和分层，这篇文章就来聊聊这个事情。
　　
　　没有顶层设计、模块划分的应用就像一团打结的毛线，代码分支可能会跳来跳来，没有边界。很难理清楚内部的业务逻辑，更糟糕的是随着需求的堆积，日积月累更难理清楚内部的模块划分，所以从一开始就应该定好系统的模块，确定好边界之后才知道每一部分往哪里放。
　　
　　每次实现一个新需求内心都有一个层次树，大概会在哪个模块加什么东西，传统的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服务发布成rpcprovider，为上游提供服务。
　　
　　其实有很多系统会把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机制，方便切流到新服务提供者上去。
　　
　　上面有的是按照层的概念说的，有的是按照模块来说的。这篇文章我自己觉得挺有价值的，工程上的一些最佳实践，希望对大家在做应用架构设计的时候有帮助。
　　
　　编辑：Harris