Naming Conventions for Java Classes

Naming Conventions for Classes in Spring / Jakarta Applications

For a modern Java application, developers use widely recognized naming conventions that make codebases easier to navigate.

Suppose you want to give a name to objects by what their class is responsible for. The table is organizing so that it show in the first column the purpose of the object and in the other columns convention to follow to give a name to a class.

A small caveat first:

• @Service, @Repository, and @Controller are Spring stereotypes.
• Jakarta EE does not provide direct equivalents for all of them.
• In Jakarta EE, developers often use @ApplicationScoped, @RequestScoped, @Singleton or EJB annotations such as @Stateless.

So the mapping is sometimes exact, sometimes only conceptual.

Complete Java/Spring Cheat Sheet

Purpose	Naming Convention	Spring Annotation	Jakarta EE / Jakarta CDI Equivalent	Example
Handle HTTP requests	*Controller	@Controller, @RestController	@Path	TicketController
Implement business logic	*Service	@Service	@ApplicationScoped or @Stateless	TicketService
Access a database	*Repository	@Repository	@ApplicationScoped	TicketRepository
Access a database (legacy)	*Dao	@Repository	@ApplicationScoped	TicketDao
Call external APIs or systems	*Client	@Component	@ApplicationScoped	EmailClient
Call external APIs or systems	*Proxy	@Component	@ApplicationScoped	TicketNotificationProxy
Integrate with external systems	*Gateway	@Component	@ApplicationScoped	PaymentGateway
Adapt one interface to another	*Adapter	@Component	@ApplicationScoped	EmailNotificationAdapter
Convert between objects/models	*Mapper	@Component (optional)	@ApplicationScoped (optional)	TicketMapper
Validate business or input rules	*Validator	@Component (optional)	@ApplicationScoped (optional)	TicketValidator
Create complex objects	*Factory	Varies	@ApplicationScoped (optional)	TicketFactory
Build complex objects step-by-step	*Builder	None	None	TicketBuilder
Handle application/domain events	*Listener	@EventListener	CDI @Observes	TicketCreatedListener
Handle commands, messages, or events	*Handler	Varies	@ApplicationScoped	CreateTicketHandler
Define framework/application configuration	*Configuration	@Configuration	Producer classes using @Produces	SecurityConfiguration
Hold configuration properties	*Properties	@ConfigurationProperties	MicroProfile Config / @ConfigProperty	MailProperties
Filter requests	*Filter	@Component + Filter	@WebFilter	JwtAuthenticationFilter
Intercept requests or method calls	*Interceptor	Spring MVC HandlerInterceptor	@Interceptor	LoggingInterceptor
Run scheduled tasks	*Scheduler	@Component + @Scheduled	@Scheduled (implementation-dependent)	TicketCleanupScheduler
Batch/background jobs	*Job	Varies	Jakarta Batch (jakarta.batch)	TicketImportJob

---

Suggested grouping

To make the table easier to memorize, I would mentally group the conventions as follows:

Layer / Concern	Common Conventions
Web/API Layer	Controller, Filter, Interceptor
Business Layer	Service, Handler, Validator
Persistence Layer	Repository, Dao
External Integrations	Client, Proxy, Gateway, Adapter
Data Transformation	Mapper, Builder, Factory
Events	Listener
Configuration	Configuration, Properties
Background Processing	Scheduler, Job

---

Domain classes

These usually don't need a suffix.

User
Ticket
Order
Invoice

The domain concept itself should have the simplest name.

---

DTOs

DTO suffixes are extremely common in Spring applications.

Suffix	Purpose	Example
Dto	Generic data transfer object	TicketDto
Request	Incoming API request	CreateTicketRequest
Response	Outgoing API response	TicketResponse
Command	Command in CQRS	PublishTicketCommand
Event	Domain/integration event	TicketPublishedEvent

---

Persistence classes

Suffix	Purpose	Example
Entity	JPA entity	TicketEntity
Embeddable	Embedded JPA type	AddressEmbeddable

---

Interfaces

In modern Java, you avoid the old I prefix:

ITicketService
IUserRepository

Prefer:

TicketService
TicketRepository
NotificationClient

with implementations such as:

DefaultTicketService
JpaTicketRepository
EmailNotificationClient

---

A simple rule of thumb

If you're starting a new Spring project today, I'd recommend this mental model:

"What responsibility does this class have?"

Then choose the suffix that matches that responsibility and mark the class with associated annotation:

• HTTP Layer → Controller → @Controller, @RestController
• Business Layer → Service → @Service
• Persistence → Repository → @Repository
• External APIs → Client or Adapter → @Component
• Mapping → Mapper → @Component (optional)
• Validation → Validator → @Component (optional)
• Events → Listener → @EventListener
• Configuration → Configuration → @Configuration

Those eight conventions cover the vast majority of classes you'll encounter in modern Spring applications. If every class in your project follows that principle consistently, other Java developers can usually understand the architecture just by reading the class names.