• Home /
  • DevOps /
  • DTO vs Entity vs Model What’s the Real Difference?

DTO vs Entity vs Model What’s the Real Difference?

By Manaswini De Software Engineer & Instructor at CodeKerdos

If you’ve spent any time building backend applications – whether in Java, Python, Node.js, or any other language – you’ve probably stumbled across the terms DTO, Entity, and Model. They sound similar, they look similar in code, and half the Stack Overflow threads just make it more confusing.

But here’s the thing: getting this right isn’t just academic. Misusing these patterns leads to bloated code, tight coupling, security leaks (ever accidentally serialized a password hash to the client?), and maintenance nightmares.

In this blog, we’ll break down exactly what each term means, where each lives in your application, and when to use which. Let’s clear up the confusion once and for all.

How Data Moves Through a Backend Application

Before diving into definitions, let’s picture how a typical HTTP request travels through a layered backend. Notice how different types appear at different stages:

For example:
Key insight: DTOs travel between external consumers and your internal services. Entities talk to your database. Domain Models hold business logic. Each has its own responsibility.

1. DTO - Data Transfer Object

What is it?

A DTO (Data Transfer Object) is a plain object whose sole job is to carry data from one place to another – typically across layer boundaries or over a network. It contains no business logic whatsoever.

Key characteristics of a DTO:

  • Contains only fields (and getters/setters or properties)
  • No business logic, no validation rules
  • Designed to be serialized/deserialized (JSON, XML)
  • Defines exactly what the API exposes - nothing more, nothing less
  • Can be versioned independently of your domain
Java Example: 
// Request DTO - what the client sends
public class CreateUserRequestDTO {
	private String name;
	private String email;
	private String password;   // raw password from client
	// getters and setters...
}

// Response DTO - what we send back
public class UserResponseDTO {
	private Long id;
	private String name;
	private String email;
	// Note: NO password field -- intentionally hidden
}

Security tip: DTOs are your API contract. By controlling which fields appear in response DTOs, you prevent accidentally leaking sensitive data like password hashes, internal IDs, or audit fields to the client.

2. Entity - Database Entity

What is it?

An Entity is a class that maps directly to a database table (or document, in NoSQL). It is the object that your ORM (Object-Relational Mapper) – like Hibernate, JPA, SQLAlchemy, or Sequelize – manages for you. When you save, update, or delete an entity, the ORM translates those operations into SQL.

Java Example:
  • Annotated with ORM-specific annotations (@Entity, @Table, etc.)
  • Fields map to database columns
  • Managed by a persistence context (tracked for changes)
  • Often includes audit fields like createdAt, updatedAt
  • Should NOT be sent directly over the network
Java / JPA Example: 
@Entity
@Table(name = "users")
public class UserEntity {
 
	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	private Long id;
 
	@Column(nullable = false)
	private String name;
 
	@Column(unique = true, nullable = false)
	private String email;
 
	private String passwordHash;  // hashed, never expose via DTO
 
	@CreationTimestamp
	private LocalDateTime createdAt;
}

Common mistake: Returning Entity objects directly from REST controllers. This exposes your DB schema, internal fields, and can cause infinite recursion with lazy-loaded relationships. Always map to a DTO first.

3. Model - Domain Model / View Model

What is it?

The term “Model” is the most overloaded of the three – it means different things in different contexts. In Domain-Driven Design (DDD), a Domain Model is a rich object that encapsulates both state and behaviour. In MVC frameworks, a “Model” might refer to a ViewModel – data shaped for a specific view. In some codebases, it’s simply the business object that sits between the DTO and the Entity.

Key characteristics of a Domain Model:
  • Represents a real-world business concept
  • Can contain business rules and methods
  • Framework-agnostic - no ORM annotations, no serialization annotations
  • May be assembled from multiple entities
  • Lives in the domain / business logic layer
Example: 
public class User {       	// Domain Model
	private Long id;
	private String name;
	private Email email;   	// Value object
	private PasswordHash hash;
 
	public void changeEmail(String newEmail) {
    	if (!EmailValidator.isValid(newEmail))
        	throw new InvalidEmailException(newEmail);
    	this.email = new Email(newEmail);
	}
 
	public boolean isActive() {
    	return this.status == UserStatus.ACTIVE;
	}
}

Side-by-Side Comparison

Aspect

DTO

Entity

Model

Purpose

Transfer data

Map to DB

Business / UI logic

Location

API / Service layer

Repository / DB layer

Domain / Presentation

Contains

Fields only

Fields + DB annotations

Fields + business rules

ORM Managed

No

Yes (JPA/Hibernate etc.)

Usually No

Validation

Input validation

DB constraints

Business rules

Serialized

Yes (JSON/XML)

Sometimes

Sometimes

Frameworks

Jackson, Gson

JPA, Hibernate, SQLAlchemy

Any

Where Each Type Lives - Layered Architecture

A well-structured backend application separates concerns into layers. Each layer has clear responsibilities, and each of our three types belongs to specific layers:

Practical Walkthrough: Creating a User

Let’s trace a real request through a Spring Boot application step by step:

Step 1 - Client sends a POST request 

POST /api/users
{
  "name": "John Doe",
  "email": "john@codekerdos.com",
  "password": "SecurePass123"
}

Step 2 - Controller receives CreateUserRequestDTO 

@PostMapping("/users")
public ResponseEntity<UserResponseDTO> createUser(
    	@RequestBody CreateUserRequestDTO request) {
	UserResponseDTO response = userService.create(request);
	return ResponseEntity.status(201).body(response);
}

Step 3 - Service converts DTO → Domain Model, applies logic 

public UserResponseDTO create(CreateUserRequestDTO dto) {
	User user = new User(dto.getName(), dto.getEmail());
	user.setPasswordHash(passwordEncoder.encode(dto.getPassword()));
	UserEntity entity = userMapper.toEntity(user);
	UserEntity saved = userRepository.save(entity);
	return userMapper.toResponseDTO(saved);
}

Step 4 - Response DTO travels back to the client 

{
  "id": 42,
  "name": "John Doe",
  "email": "john@codekerdos.com"
  // password hash: NOT here
}

Common Mistakes to Avoid

❌ Returning Entity directly from a REST controller. Always map to a DTO – you risk exposing DB internals and lazy-load exceptions.

❌ Returning Entity directly from a REST controller. Always map to a DTO – you risk exposing DB internals and lazy-load exceptions.

❌ Skipping the Domain Model in simple CRUD apps. Fair – but as complexity grows, you’ll regret not having a clean business layer.

✅ Use a Mapper (MapStruct, ModelMapper, or hand-coded) to convert between DTO ↔ Entity ↔ Model. Never scatter conversion logic across your codebase.

Quick Decision Guide

Ask yourself these questions when deciding which type to reach for:

  • Am I sending data over the network or between layers? → Use a DTO
  • Am I reading from or writing to a database via ORM? → Use an Entity
  • Am I encoding business rules or behavior? → Use a Domain Model
  • Am I shaping data for a UI component? → Use a ViewModel (a DTO variant)

Frequently Asked Questions (FAQs)

A DTO (Data Transfer Object) is used to transfer data between layers or systems without exposing internal business logic or database structures.

A DTO transfers API data, while an Entity maps directly to database tables managed by an ORM like Hibernate or JPA.

Exposing Entities can leak sensitive database fields, create tight coupling, and cause serialization or lazy-loading issues.

A Domain Model represents business concepts and contains business logic independent of frameworks or databases.

Layered architecture separates applications into presentation, business, service, and database layers for better maintainability and scalability.

Use DTOs when transferring data between clients, APIs, services, or application layers.

Conclusion

The DTO, Entity, and Model pattern is one of those architectural decisions that seems pedantic at first but pays enormous dividends as your application scales. To recap:

  • DTOs are your API contract - shape data for transport, hide internals
  • Entities are your database mapping - let the ORM manage their lifecycle
  • Domain Models are your business core - pure logic, no framework leakage

Keeping these three types distinct might feel like extra boilerplate in a tiny app. But it gives you clean layer boundaries, easier testing, better security, and the freedom to change your DB schema without breaking your API.

Scroll to Top