服务接口规范
作为一家互联网公司，并且大部门属于电商部门，系统必须支持根据业务的扩张，实现横向扩展，因此系统基础采用分布式横向扩展方式设计，使用OpenApi实现统一外部接入接口规范，使用dubbo实现内部服务负载规范，使用Restful实现内部管理接口规范
采用API开发
系统基于领域驱动开发，根据业务划分，研发部门按照各自负责的领域并行开发，系统之间存在提供或者依赖基础服务的情况。
传统：采用SOA/WebService服务，有SOAP、WSDL等语法定义服务规范，需要存在SA/BA的角色先按照业务需求定义好WSDL，WSDL定义完整，但是由于定义完整，存在严格的规范限制，制约了性能，每次都需要通过SAX等工具生成客户端，每次提供的WSDL有变更都需要额外生成对应的客户端代码。（还有存在自身不具备负载的能力，需要依赖F5、Nginx等实现前置负载，虽然有类似于Oracle公司的ESB等集成工具，但是很贵，很贵，很贵！！！）
当下：基于敏捷开发，快速迭代，横向扩展的形势下，采用基于定义接口，提供API依赖包，轻依赖，接口变更只需要更新依赖版本，变动较少，语法没有强约束，性能损耗少，由于存在较少约束，不会受限于业务变更。
工程规范
对外提供的服务接口以及内部处理的业务逻辑，在工程上划分为
project
- project-biz (实现对外暴露接口业务逻辑)
- main
- common(aop,convert,util)
- conf
- dao
- mapper(对每一张表具体实体操作)
- single
- tddl
- repo(集成封装了mapper成为业务级实体变更，外部只能应用repo)
- single
- impl
- XXXInterface
- tddl
- diamond
- exceptions
- manager
- impl(XXXInterfaceImpl, 只能操作dao.repo,common,diamond)
XXXInterface
- model
- service(只能操作manager,diamond实例)
- mq
- task(定时任务)
ApplicationMain
- test
- ut (单元测试)
- it (集成测试)
- project-client (对外暴露接口)
- api (接口)
- dubbo
- gw
- web
- model (数据模型)
- enumus
- dubbo
- gw
- web
- util
DTO,DO,PO,DAO,POJO数据域使用
在数据域这块有两个分歧点，纠结点来源于dao层的技术选型以及对domain的理解，一方使用 JPA（部分部门） 做持久层操作，一方使用 mybatis（部分部门） 做持久层操作。
下方是2套技术的比较，在持久化层面的区别只是基于对持久层的理解，但是在manager-> service 领域层的理解，出现了较大的理解偏差。本身不是JPA(spring-data)和mybatis技术的问题，而是2个项目的成员对于domain分层上面理解程度存在偏差。
- mapper:
JPA -> Repository，请求/响应对象 PO
mybatis -> xml mapper，请求/响应对象 DAO - repo:
JPA -> 操作 mapper 层, 请求/响应对象 PO
mybatis -> 操作 mapper 层, 请求对象 DTO，响应对象 DO，对数据的整合在此层完成，主表-子表的封装在这层实现 - manager:
JPA -> 操作 repo, common, manager 等层，请求基础类型、DO、DTO、POJO，响应基础类型、DO、DTO、POJO， 这里非常混乱，没有一个标准的规范，manager之间允许相互调用
mybatis -> 操作 repo, common 等层，请求 XxxParam、XxxQuery、DTO，响应 Result/Batch/PageDTO<DO>、基础类型，manager类型不允许相互调用。即使多个manager存在调用同样的外部service问题，也作为冗余，如果有大量这种情况，有必要抽象成基础的AbstractBaseManager。
DO作为领域对象，可以囊括领域中所有的数据 - service:
JPA -> gw入参是primitive类型，dubbo入参是DTO，http入参是DO，gw出参是DTO/Collection，dubbo出参是POJO，http出参是POJO
mybatis -> gw入参primitive类型，dubbo入参是primitive类型，web入参是XxxParam，gw出参是业务类型命名的XxxGW，dubbo出参是Result/Batch/PageDTO<DTO>，web出参是DTO
