DTO

A DTO (Data Transfer Object) is a plain Java object used to transfer data between layers. It separates your API contract from your database model.

Why DTOs?

Entity (Database)           DTO (API)
┌─────────────────┐        ┌─────────────────┐
│ id              │        │ id              │
│ name            │        │ name            │
│ passwordHash    │ ← NO → │                 │
│ internalField   │ ← NO → │                 │
│ category        │ ← NO → │ categoryName    │
│ reviews         │ ← NO → │ averageRating   │
│ createdAt       │        │                 │
│ updatedAt       │        │                 │
└─────────────────┘        └─────────────────┘

Reasons to use DTOs:

1. Security — don't expose passwords, internal fields
2. Flexibility — change API without changing database
3. Performance — load only the data clients need
4. Decoupling — API and database can evolve independently

Response DTOs

public class ProductDto {
    private Long id;
    private String name;
    private String description;
    private BigDecimal price;
    private String categoryName;
    private Integer reviewCount;
    private Double averageRating;

    // Constructors
    public ProductDto() {}

    // Getters and Setters
    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public BigDecimal getPrice() { return price; }
    public void setPrice(BigDecimal price) { this.price = price; }
    // ...
}

Request DTOs (Input Validation)

public class CreateProductRequest {

    @NotBlank(message = "Product name is required")
    @Size(min = 2, max = 255, message = "Name must be 2-255 characters")
    private String name;

    @Size(max = 2000, message = "Description must be at most 2000 characters")
    private String description;

    @NotNull(message = "Price is required")
    @DecimalMin(value = "0.01", message = "Price must be at least 0.01")
    private BigDecimal price;

    @NotNull(message = "Category ID is required")
    private Long categoryId;

    @NotNull(message = "Stock quantity is required")
    @Min(value = 0, message = "Stock cannot be negative")
    private Integer stockQuantity;

    // Getters and Setters
}

Separate DTOs for Different Operations

// Create — no ID (server generates)
public class CreateProductRequest {
    private String name;
    private BigDecimal price;
    private Long categoryId;
}

// Update — no ID in body (ID comes from URL)
public class UpdateProductRequest {
    private String name;
    private BigDecimal price;
    private String description;
}

// Response — includes ID and computed fields
public class ProductDto {
    private Long id;
    private String name;
    private BigDecimal price;
    private String categoryName;
    private LocalDateTime createdAt;
}

Record DTOs (Java 16+)

public record ProductDto(
    Long id,
    String name,
    String description,
    BigDecimal price,
    String categoryName,
    Integer reviewCount,
    Double averageRating
) {}

public record CreateProductRequest(
    @NotBlank String name,
    @Size(max = 2000) String description,
    @NotNull @DecimalMin("0.01") BigDecimal price,
    @NotNull Long categoryId,
    @NotNull @Min(0) Integer stockQuantity
) {}

Records are immutable, concise, and include equals(), hashCode(), toString() for free.

Key Principles

1. Follow SOLID principles
2. Write clean, readable code
3. Test thoroughly
4. Document decisions
5. Monitor in production

Implementation

• Start simple, refactor as needed
• Use established patterns
• Consider trade-offs
• Review with peers

Continuous Improvement

• Learn from incidents
• Update documentation
• Share knowledge
• Mentor others

Key Points

• Understanding DTO is essential for production systems
• Always consider scalability and maintainability
• Test thoroughly before deploying to production
• Monitor performance and set up alerting

Common Patterns

1. Validation: Always validate input at the boundary
2. Error Handling: Use structured error responses
3. Logging: Log key events for debugging
4. Testing: Unit, integration, and load tests
5. Documentation: Keep docs updated with code changes