Now I study about the Spring Boot that with JAVA platform.

A problem I faced is how can you tell the difference between DTO, VO, Entity, Domain, and Model.

Honestly it all look too similar to tell the difference.

I already checked some stackoverflow answers about "Difference between DTO and VO" and something like that.

However, I am still wondering how do they different each other in terms of developer with Spring Boot.

CodePudding user response：

• Entity - is a class with an ID. In the case of relational DB it's usually a class that's mapped to a DB table with some primary key.
• DTO (Data Transfer Object) - is a class that maps well on what you're sending over the network. E.g. if you exchange JSON or XML data, it usually has fields just enough to fill those requests/responses. Note, that it may have fewer or more fields than Entity.
• VO (Value Object) is a class-value. E.g. you could create class like Grams or Money - it will contain some primitives (e.g. some double value) and it's possible to compare Value Objects using these primitives. They don't have a database ID. They help replacing primitives with more object-oriented classes related to our particular domain.
• Domain Model contains all Entities and Value Objects. And some other types of classes depending on the classification you use.

In order to get acquainted with these you should read:

• Enterprise Application Patterns by Fowler. Mentions Value Object and Domain Model.
• Domain Driven Design by Eric Evans. Mentions Entity, Value Object and Domain Model.
• And maybe get acquainted with Java EE design patterns. They mention DTO. But these are pretty badly written articles (if they are still even available on the internet). Confusingly, they also had Value Object which was defined very similarly to DTO, but no one uses that definition of VO.

CodePudding user response：

These are just words, there is no general agreement over what they precisely mean.

They have different meanings in different projects, and part of onboarding a project is learning those project-specific definitions.

Also, the definitions of the words - overlap, since they were not invented "at one go", but rather traditionally used in influential books, blogs etc/

For example:

• DTO is a concept from the early 2000s; back then, the official J2EE Java mandated using (long forgotten and deprecated) "entity EJBs" for interacting with the database. It turned out that the best pattern for using them was to create additional "Transfer Objects", just for managing communication between DAOs and "session ejbs" (nowadays known as "services"). Then Hibernate came along, bringing the "transparent persistence" and the idea that "we don't need separate DTOs, we can just use the POJO entities". Shortly after, J, PA was born. In the general mind the "DTOs" became "entities", and the name DTO was reused for "any type of data which is packaged for interfacing with external systems".
• VO is often used for "read only type of DTO". But sometimes, in Domain Driven Design, people use this term to contrast domain objects: "entities" are the objects that can change and remain "the same", while the "value objects" are things that cannot change, because they would "become something else". For example a car can change it's color, and it's still "the same car". On the other hand, the date "1977-04-05" cannot "mutate" into "2011-04-05", because it will simply become some other date.

Takeaways:

• there's never the need to know abstract definitions of the words. You will always need to understand them in context;
• don't believe (nor trust) people who try and tell you "absolute truths" about those definitions. You will always find equally smart people claiming something completely different.
• there's no royal road to understanding software architecture, no "brief summary". It's more like philosophy or history than, say, engineering.

CodePudding user response：

Summary

1. An Entity:
   Is a lightweight persistence domain object. Typically, an entity represents a table in a relational database, and each entity instance corresponds to a row in that table. The primary programming artifact of an entity is the entity class, although entities can use helper classes.

2. DTO (Data Transfer Object):
   Are containers which are used to transport data between layers and tiers.

   When you're working with a remote interface, each call is expensive and the number of calls should be reduced. The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects. It's often little more than a bunch of fields and the getters and setters for them.

3. VO - A Value Object:
   Represents itself a fixed set of data and is similar to a Java enum.

   A Value Object's identity is based on their state rather than on their object identity and is immutable. A real world example would be Color.RED, Color.BLUE, SEX.FEMALE etc.

4. Domain Model:
   Contains all Entities and Value Objects. And some other types of classes depending on the classification you use.

5. Model:
   Defines a holder for model attributes and is primarily designed for adding attributes to the model.

6. ModelMap:
   Is an extension of Model with the ability to store attributes in a map and chain method calls.

7. ModelAndView:
   Is a holder for a model and a view; it allows to return both model and view in one return value.

   Model, ModelMap, and ModelAndView are used to define a model in a Spring MVC application.

8. DAO (Data Access Object) or Repository:
   A Data Access Object abstracts and encapsulates all access to the data source. The DAO manages the connection with the data source to obtain and store data.

   The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, or a business service accessed via REST or SOAP.

   The DAO abstracts the underlying data access implementation for the Service objects to enable transparent access to the data source. The Service also delegates data load and store operations to the DAO.

9. Service: A Service Layer defines an application's boundary and its set of available operations from the perspective of interfacing client layers.

   It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations.

   Though Putting business logic here is an anti-pattern introduced around the times of EJB 1.x and 2.x. Preferably, you should put the business-related functionality into Domain Model. Read about Anemic vs Rich Model: Anemic architecture - enemy of testing

Layers

Before understanding the Spring Boot Architecture, you must know the different layers and classes present in it. There are four layers in Spring Boot are as follows:

1. Presentation Layer:
   The presentation layer handles the HTTP requests, translates the JSON parameter to object, and authenticates the request and transfer it to the business layer. In short, it consists of views i.e., frontend part.

2. Business Layer:
   The business layer handles all the business logic. It consists of service classes and uses services provided by data access layers. It also performs authorization and validation.

3. Persistence and Database Layer:
   The persistence layer contains all the storage logic and translates business objects from and to database rows. This is also where CRUD (create, retrieve, update, delete) operations are performed.