微服务工程打包exe文件 微服务工程目录结构

请先参考

项目架构规范：阿里规约，MVC架构以及三层架构(一)

项目架构规范：阿里规约，MVC架构以及三层架构(二)

项目架构规范：阿里规约，MVC架构以及三层架构(三)

分层目录要点

1. 严格区分每层的职责
2. 严格确定分层的调用链路
3. 严禁使用map/json等格式做数据传递
4. 严禁使用BeanUtil.Copy等方法转换

分层目录结构

总体分为应用层、业务领域层和基础设施层

应用层

应用层用于接收外部的请求，是整个系统所提供能力的外观，包含API、MQ-Listener等。专用于处理和业务无关的操作，包含验签、参数校验、拦截等处理，不实现业务逻辑通过编排业务领域和外部请求，对外提供细粒度的能力

• API:接收来自外部的HTTP请求，只做参数校验、业务领域数据组装、业务逻辑编排和响应请求
• MQ:监听消息队列的请求，不做业务处理
• Model:用于封装外部的请求参数、封装响应外部参数，与底层数据存储的结构完全无关
• Assembler：用于Model与业务领域层的Model之间的相互转换工作,例如：使用反射机制自动beanutils相互转换
• Configuration：全局的配置信息或处理，例如：全局参数校验机制、全局异常处理等

业务领域层

业务领域层主要用于实现业务逻辑，包含业务规则、策略和流程

• Model:用于接收或响应来自应用层的业务属性，同时可承载Model的行为避免失血模型。业务层只负责业务，与具体的表现形式无关，所以它返回的Model不应该出现与表现形式的耦合。
• Repository:仓储层用于对持久化通用操作的封装，将领域对象持久化，屏蔽了持久化层的特性
• Service:处理业务逻辑，对Repository和External的操作编排
• External：封装对外部的请求，包含了请求的定义、参数等

基础设施层

基础设施层为以上各层提供技术支持，例如持久化操作、公用的操作等

• Commons:共用的操作类、工具类等
• Persistence：直接面向DB的操作

命名规范

为什么要分出这个external这个包，是为了以后向微服务架构转型，尤其是Spring+Feign，会带来极大的便利！如果请求远程的服务和服务器提供的服务混杂在一起，整理项目的时候会十分混乱！

分层调用路径