Designing a Unified Base Package for Backend Projects: Maven Dependencies, Standardized Response Body, and Data Object Segmentation

The article begins by listing common pain points in Java backend projects, such as inconsistent response codes, unclear PO/DTO/BO/VO distinctions, scattered utility classes, and duplicated constants.

It then proposes placing all business‑independent, tool‑type definitions into a unified base package, allowing the core business modules to focus on domain logic.

Base Package Maven Dependency Guidelines

Only dependencies that are business‑agnostic, utility‑oriented, and require no additional configuration should be added. Example of acceptable dependencies:

<dependency>
  <groupId>com.baomidou</groupId>
  <artifactId>mybatis-plus-extension</artifactId>
</dependency>
<dependency>
  <groupId>com.alibaba</groupId>
  <artifactId>transmittable-thread-local</artifactId>
</dependency>
<dependency>
  <groupId>com.google.code.gson</groupId>
  <artifactId>gson</artifactId>
</dependency>
<dependency>
  <groupId>cn.hutool</groupId>
  <artifactId>hutool-all</artifactId>
</dependency>

Dependencies that tie to specific frameworks or databases (e.g., mybatis-plus-boot-starter , druid-spring-boot-starter , mysql-connector-java ) are discouraged.

Standardized Response Body and Business Codes

To avoid relying solely on HTTP status codes, a unified JSON response structure is defined:

{
  "code": 200,               // business code
  "errorCode": null,         // internationalized error identifier
  "message": "请求成功",   // human‑readable message
  "traceId": "",           // correlation ID for distributed tracing
  "data": null               // payload
}

For paginated lists, additional fields total and an array data are included.

Correct Segmentation of Data Objects

The article distinguishes several object types and their responsibilities:

PO : Persistence object, maps one‑to‑one with database tables.

BO : Business object, aggregates PO data and contains business logic.

DTO : Data Transfer Object, used between service, RPC, and controller layers, contains no logic.

VO : View Object, tailored for presentation layer responses.

Query : Parameter object for incoming query criteria.

Command : Parameter object for write operations (create, update).

Examples illustrate how a user entity should be split so that sensitive fields like password never reach the front end.

DDD‑Oriented Design

When using Domain‑Driven Design, entities implement a marker interface such as AggregateRoot to indicate their role:

/**
 * 聚合根标记
 */
public interface AggregateRoot extends MarkerInterface {}

/**
 * 用户聚合根
 */
public class User implements AggregateRoot {}

Unified Pagination Parameters

A base pagination class combines both limit/offset and pageSize/pageNo styles, allowing any concrete query class to inherit it, e.g.:

@Data
@EqualsAndHashCode(callSuper = true)
public class KeywordQuery extends PageQuery {
    @ApiModelProperty("关键字查询")
    private String keyword;
}

Base PO Design

All persistent entities extend a common base class providing id , creation/modification timestamps, and a soft‑delete flag:

@Data
public class BaseUuidEntity {
    @TableId
    private Long id;
    private LocalDateTime gmtCreate;
    private LocalDateTime gmtModified;
    @TableLogic(delval = "current_timestamp()")
    private Long deleted;
}

Reusable Generic DTOs

Simple key/value structures are also placed in the base module for wide reuse:

@Data
@NoArgsConstructor
@AllArgsConstructor
public class DataDictDTO {
    @ApiModelProperty("key值")
    private String key;
    @ApiModelProperty("value值")
    private String value;
}

The article concludes by summarizing the four main contributions: Maven dependency guidelines, unified response format, proper POJO layering, and generic reusable types, emphasizing their importance for clean, maintainable backend architecture.