上一篇关于如何编写代码的文章提到了应用程序的模块化和分层。这篇文章将讨论这个问题。没有顶层设计和模块划分的应用就像一根打结的纱线，代码分支可能会无边界地跳来跳去。内部业务逻辑很难理清，更糟糕的是随着需求的积累，内部的模块划分更难理解。因此，系统模块应该从一开始就确定，确定了边界之后才知道各部分的边界。放。每实现一个新的需求，心里就有一个层次树，大概哪个模块会加点东西。传统的MVC模型在Web应用程序中流行了很长时间，而且很容易理解。下面我在之前实现的一个系统的基础上做了一些剪枝和设计，形成了一个比较通用的分层架构。如下图所示：后面会分别说明各个模块的职责。大家应该对应用程序分层和模块化控制器控制器层很熟悉了。写过web应用的都知道，这里是http请求的入口。控制器负责接受网页请求HttpRequest并返回HttpResponse。biz-service-api业务服务层的接口定义，一般简单的应用不需要区分biz-service和core-service，但是如果业务复杂度比较高，最好的做法是把service拆分成第二个层，而biz-service负责业务逻辑，业务逻辑复杂多样，随时会发生变化，而那些通用的基础能力，有时也称为平台能力，都放在core-services中。例如，很多业务需要支付能力，支付服务可以作为平台。能力放在core-service中，提供给biz-service。biz-service使用core-service的能力。在阿里内部体系中，非常重视core-service。如果把系统拆分成域，core-service可以理解为中台，biz-service就是前台。大中小前台除了组织架构外，策略也可以体现在应用上。一般加强中台能力，前端能力负责灵活高效满足业务需求。门面界面有点像设计模式中的门面。facade模块只定义接口，具体实现放在biz-service-impl模块中。Facade一般提供给外部系统，打包成jar包。人们依赖你。他们只需要知道接口定义的输入输出参数，他不需要关心具体的实现。您的门面服务作为rpc提供者发布，以向上游提供服务。其实很多系统都会把facade层放在core-service层下面，因为facade提供的服务被认为是rpc服务，一般只在内部发布，但是我觉得放在controller层的逻辑比较流畅清晰。当然，也是因为内部系统调用了我的controller，所以我对他们一视同仁。biz-service-impl的业务逻辑实现实现了门面接口和biz-service-api。core-service-api核心能力服务API定义。支付能力、模型运行能力、通用对象定位能力、安全等核心原子能力的定义。core-domain在这里承载核心域，最重要的模型都放在这个模块中。除了模型，这里的一些架构设计也阻止了model-service，但是我还是觉得模型更多的是一个数据的概念，模型的操作应该是Self-contained的，也就是对模型只依赖于自身的数据，可以直接在模型内部完成。如果需要多个模型参与运算，应该交给core-service来完成。它是DDD领域驱动设计的一种折衷。可理解性有时比规范更重要。这方面的例子很多。比如大型互联网公司的表设计没有遵循数据库规范的范式，很少有表连接。还有很多其他情况。基于基础设施的系统基础设施，如数据库、缓存、消息队列、流程引擎、审批流、定时任务、第三方外部系统依赖等都放在这一层。一般来说，我的建议是每次引入第三方服务或组件时，定义service-api和serviceImpl。api是通用的，不依赖于特定第三方的存在。不合适，在不好用的时候，api层不用动，不会影响上层应用的服务，还可以很好的支持SPI机制，方便切换到新的服务提供商。以上有的是基于层的概念，有的是基于模块的概念。个人觉得这篇文章还是挺有价值的，工程中的一些最佳实践，希望对大家在设计应用架构时有所帮助。
