Understanding VO, DTO, DO, and PO: Concepts and Their Application in Three‑Tier Architecture

Concepts: VO (View Object) encapsulates data for the presentation layer; DTO (Data Transfer Object) carries data between presentation and service layers; DO (Domain Object) represents business entities abstracted from the real world; PO (Persistent Object) maps directly to database structures.

The article describes how a user request is first captured as a VO, transformed into a DTO for the service layer, then into a DO for business logic, and finally into a PO for persistence, illustrating the flow with a simple sequence diagram.

VO vs. DTO: Although their attributes often overlap, VO represents data needed for display, while DTO defines the contract between presentation and service layers; keeping them separate maintains a clear separation of concerns.

When to combine VO and DTO: If requirements are stable and only a single client exists, merging them reduces boilerplate; however, customization across multiple clients or UI styles favors keeping them distinct.

DTO vs. DO: DTO is a flat, two‑dimensional data carrier, while DO contains business logic and may have richer relationships; DTO should avoid exposing unnecessary fields (e.g., passwords) and should be flattened to reduce network overhead.

DO vs. PO: DO and PO often correspond one‑to‑one, but PO may contain persistence‑only fields (e.g., version for optimistic locking) that are irrelevant to the domain model, and some DOs may not require persistence at all.

The article also discusses ORM considerations (e.g., lazy loading, transaction boundaries), the impact of exposing DOs to the presentation layer, and best practices for handling non‑persistent attributes using annotations like @Transient.

Finally, it emphasizes the principle that analysis/design concerns and implementation concerns are separate; even if technology allows merging concepts, designers should keep them conceptually distinct to maintain clarity and flexibility.