I have compiled a table for easy reference on Dto, Vm, Vo, Entity, Domain, Bean, and Pojo, which are commonly used concepts in object-oriented programming.
Please note that this table is not a strict convention to be followed, and in actual development, you should refer to it based on your specific needs rather than blindly applying it.
In this scaffold, I have not strictly adhered to all the concepts listed in the table but have used some of them based on the actual requirements.
You can find the scaffold at the following URLs:
Most of the time, I use entities, DTOs, and view models (VMs). When my project grows larger, I introduce domain objects and value objects (VOs).
| Suffix | Definition | Purpose | Note | Three-Layer Architecture |
|---|---|---|---|---|
| DTO | Data Transfer Object. Usually contains only properties and getter/setter methods, no business logic. | Used to transfer data between different layers of the application | Immutable. | Service |
| VM | View Model. Typically represented by immutable objects such as records. | Maps data in the view and decouples the view from the model | Immutable. | Controller |
| Entity | Entity Object. Typically contains the properties and behavior of an entity, but not complex business logic. | Represents entities or objects in the business domain, such as users, orders, products, etc. Part of the domain model. Typically created and managed by the data access layer. | Has an independent lifecycle. | DAO |
| Vo | Value Object. An immutable object whose value does not change after creation. It does not contain business logic or complex computations. | A standalone class that does not directly depend on business logic or the data access layer. Typically created and managed by the domain model or service layer to represent simple values. | Does not have an independent lifecycle. Requires defining the equals method. | Service |
| DO (Domain Object) | Domain Model. Typically holds multiple class members such as entities, value objects, etc., that constitute the business aspects of the domain, and includes complex methods implementing business logic. | Used to represent the business concepts and rules of a specific domain, encapsulating the business logic and behavior of the application. | Has an independent lifecycle. The lifecycle of the value objects it holds depends on the domain model. | Service |
| Name | Definition | Purpose |
|---|---|---|
| Bean | Follows specific rules. Must have a no-arg constructor and properties accessed using getter and setter methods. | Suitable for transferring data between different layers or encapsulating business-agnostic functionality such as objects managed by the Spring container. |
| Pojo | Plain Old Java Object, with no specific restrictions. | Suitable for various scenarios, especially those related to business, such as mapping database entities. |
By the way, as a side note, if this table or scaffold is helpful to you, you may consider giving me a star. It would be a great encouragement for me. Thank you for your generosity!
Top comments (0)