后端开发实践系列——Spring Boot项目模板

对于gradle而言，我们刻意地将Gradle插件脚本与插件配置放到了一起，比如Checkstyle：

├── gradle 
│   ├── checkstyle 
│   │   ├── checkstyle.gradle 
│   │   └── checkstyle.xml 

事实上，在默认情况下Checkstyle插件会从项目根目录下的config目录查找checkstyle.xml配置文件，但是这一方面增加了多余的文件夹，另一方面与该插件相关的设施分散在了不同的地方，违背了广义上的内聚原则。

基于业务分包

早年的Java分包方式通常是基于技术的，比如与domain包平级的有controller包、service包和infrastructure包等。这种方式当前并不被行业所推崇，而是应该首先基于业务分包。比如，在订单示例项目中，有两个重要的领域对象Order和Product(在DDD中称为聚合根)，所有的业务都围绕它们展开，因此分别创建order包和product包，再分别在包下创建与之相关的各个子包。此时的order包如下：

├── order 
│   ├── OrderApplicationService.java 
│   ├── OrderController.java 
│   ├── OrderNotFoundException.java 
│   ├── OrderRepository.java 
│   ├── OrderService.java 
│   └── model 
│       ├── Order.java 
│       ├── OrderFactory.java 
│       ├── OrderId.java 
│       ├── OrderItem.java 
│       └── OrderStatus.java 

可以看到，在order包下我们直接放置了OrderController和OrderRepository等类，而没有必要再为这些类划分单独的子包。而对于领域模型Order来讲，由于包含了多个对象，因此基于内聚性原则将它们归到model包中。但是这并不是一个必须，如果业务足够简单，我们甚至可以将所有类直接放到业务包下，product包便是如此：

└── product 
    ├── Product.java 
    ├── ProductApplicationService.java 
    ├── ProductController.java 
    ├── ProductId.java 
    └── ProductRepository.java 

在编码实践中，我们总是基于一个业务用例来实现代码，在技术分包场景下，我们需要在分散的各包中来回切换，增加了代码导航的成本;另外，代码提交的变更内容也是散落的，在查看代码提交历史时，无法直观的看出该次提交是关于什么业务功能的。在业务分包下，我们只需要在单个统一的包下修改代码，减少了代码导航成本;另外一个好处是，如果哪天我们需要将某个业务迁移到另外的项目(比如识别出了独立的微服务)，那么直接整体移动业务包即可。

当然，基于业务分包并不意味着所有的代码都必须囿于业务包下，这里的逻辑是：优先进行业务分包，然后对于一些不隶属于任何业务的代码可以单独分包，比如一些util类、公共配置等。比如我们依然可以创建一个common包，下面放置了Spring公共配置、异常处理框架和日志等子包：

└── common 
    ├── configuration 
    ├── exception 
    ├── loggin 
    └── utils 

自动化测试分类

在当前的微服务和前后端分离的开发模式下，后端项目仅提供纯粹的业务API，而不包含UI逻辑，因此后端项目不会再包含诸如WebDriver的重量级端到端测试。同时，后端项目作为向外提供业务功能的独立运行单元，在API级别也应该有相应的测试。

此外，程序中有些框架性代码，要么是诸如Controller之类的技术性框架代码，要么是基于某种架构风格的代码(比如DDD实践中的ApplicationService)，这些代码一方面并不包含业务逻辑，一方面是很薄的一个抽象层(即实现相对简单)，用单元测试来覆盖显得没有必要，因此笔者的观点是可以不为此编写单独的单元测试。再者，程序中有些重要的组件性代码，比如访问数据库的Repository或者分布式锁，使用单元测试实际上“测不到点上”，而使用API测试又显得在分类逻辑上不合理，为此我们可以专门创建一种测试类型谓之组件测试。

基于以上，我们可以对自动化测试做个分类：

• 单元测试：核心的领域模型，包括领域对象(比如Order类)，Factory类，领域服务类等;
• 组件测试：不适合写单元测试但是又必须测试的类，比如Repository类，在有些项目中，这种类型测试也被称为集成测试;
• API测试：模拟客户端测试各个API接口，需要启动程序。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!