只是要清楚一点，由于问题非常棘手，因此answer绝不是实现only的project structure and versioning方法。可能还有许多其他方法，我只是在分享我以前使用过的相关内容。
显然，有多种不同的方式来构建代码库
基于层的项目结构
基于功能的项目结构
在Layer-based project structure中，代码是根据所拥有的不同类型的层（即控制器，服务等）构造的，而在Feature-based project structure中，代码是根据系统的features构造的，请阅读here以获取更多信息。
在线上有很多资源可以展示不同类型的包结构，我个人坚持使用layer-based project structure，因为我更喜欢基于layers而不是功能来组织代码库。
项目结构
入门项目骨架的一种非常简单的方法是查看一些示例Spring webapps。例如，我转到Spring Initializer并选择以下内容
项目名称（即myproj）
组名（即com）
选择模块（即REST，JPA等）
生成
现在，我有一个基于REST的Spring Boot项目，可用作我的layers对其进行自定义的框架。您不必使用Spring Boot，但是，我试图展示的是Spring Boot推荐的REST Web服务项目结构。
我通常有以下几层
控制者
道
服务
模型
dto
例外
验证器
效用
依此类推，这是项目结构的屏幕截图
unit test包的结构如下所示，您可以想象其余测试类的外观。
如果您有integration test或在Java应用程序本身中引用了end to end test，则需要
src/integ-test/java
src/integ-test/resources
端点版本控制
版本终结点可能有不同的方法。我以前使用的一种方法是
GSON's versioning support，它可能对您不起作用，但无论如何在这里共享它。
如果您在上面的屏幕截图中注意到了以下软件包
com.myproj.dto.inbound
com.myproj.dto.outbound
DTO代表
Data Transfer Object，如上所示，
UserInDTO.java是请求中出现的
User.java对象的表示，您将在控制器的端点中将它与
@RequestBody一起使用。
UserOutDTO.java是出现的
User.java对象的表示。使用DTO时
您可以针对系统使用者看到的内容以及模型中使用的内容采用不同的命名约定（即
User.java）
您可以在传出和传入
include中的
exclude和
DTOs字段，而无需对模型/业务对象（即
User.java）进行不必要的更改
现在已经有了DTO，并且如果使用的是
GSON，则可以使用
Versioning和
include等注释将其的
exclude功能用于
UserOutDTO.java和
@Since(1.5)字段中的
@Until(2.3)。由于
GSON是序列化/反序列化库，或者换句话说，它将
JSON转换为
Java Object，反之亦然，因此它可以在
include和
exclude字段之前将
Object转换为< cc>，您可以通过编写序列化和反序列化适配器来实现更多方法。
这是
JSON的示例，以及在特定版本之后如何对字段进行版本控制以包括和排除
public class UserOutDTO {
@Expose
@SerializedName("User id")
private int id;
@Expose
private String firstName;
@Expose
private String lastName;
/*
* This field will become available for all requests coming for version 2.0 onwards. For a request before
* version 2.0 the address field won't be available.
*/
@Expose
@Since(2.0)
private String address;
/*
* This field will become available after version 3.0 an example when you extend your model
*/
@Expose
@Until(3.0)
private String nickname;
//Getters and Setters
}
希望对您有所帮助。您也可以查看此问题，有很多非常有用的答案
Package structure for a Java project?