JPA를 처음 배울 때 가장 헷갈리는 부분 중 하나가 "왜 파일을 Domain, Repository, Service로 나누지?" 였다.
그래서 전체 흐름을 먼저 정리해보자면 ...
사용자 요청
↓
Controller (요청 받기)
↓
Service (비즈니스 로직 처리)
↓
Repository (DB 접근)
↓
Database
그리고 Domain은 이 시스템에서 관리하는 핵심 데이터(객체)보면 된다.
📁 예:
domain
└── Member.java
도메인은 서비스가 다루는 핵심 대상이다.
쉽게 말하면:
"우리 프로그램에서 어떤 것을 관리할 것인가?"
예를 들어 쇼핑몰이면:
회원(Member)
상품(Item)
주문(Order)
같은 것들이 도메인이다.
예:
@Entity
public class Member {
@Id
@GeneratedValue
private Long id;
private String name;
private String email;
}
이 클래스는 DB의 member 테이블과 연결됩니다.
즉:
Member 객체
↓
member 테이블
이렇게 매핑되는 것이다.
JPA에서는 보통 Entity = Domain 객체라고 생각하면 된다.
📁 예:
repository
└── MemberRepository.java
Repository는 DB와 통신하는 역할이다.
쉽게 말하면:
"데이터를 저장하고 조회하는 창구"
예:
@Repository
public interface MemberRepository
extends JpaRepository<Member, Long> {
}
그러면 JPA가 기본적인 DB 기능을 만들어준다.
예:
memberRepository.save(member);
→ 회원 저장
memberRepository.findById(1L);
→ 회원 조회
흐름:
Service
|
↓
MemberRepository
|
↓
Database
📁 예:
service
└── MemberService.java
Service는 비즈니스 로직을 처리하는 곳이다.
예를 들어 회원가입을 한다면:
Controller:
회원가입 요청 받음
↓
Service:
1. 이름 중복 확인
2. 회원 생성
3. 저장 요청
↓
Repository:
DB 저장
이런 구조이다.
예:
@Service
@Transactional
public class MemberService {
private final MemberRepository memberRepository;
public Long join(Member member){
validateDuplicateMember(member);
memberRepository.save(member);
return member.getId();
}
private void validateDuplicateMember(Member member){
// 중복 회원 검사 로직
}
}
세 개를 비교하면
구분 역할 비유
Domain 관리할 데이터와 상태 회원이라는 사람 자체
Repository DB 저장/조회 회원 정보 창고
Service 업무 규칙 처리 회원가입 담당 직원
예를 들어 회원가입 요청이 들어오면:
POST /members
↓
Controller
"회원가입 해줘"
↓
MemberService
"이미 가입한 회원인지 확인하고 저장하자"
↓
MemberRepository
"DB에 Member 저장"
↓
Database
member 테이블
처음 JPA 프로젝트 구조는 보통 이렇게 간다.
src
└── main
└── java
└── jpashop
├── domain
│ └── Member.java
│
├── repository
│ └── MemberRepository.java
│
├── service
│ └── MemberService.java
│
└── controller
└── MemberController.java