LUMI_dev
1달 역량평가_DailyReport0424 본문
**오늘 날짜 :** 2025-04-24
**진도 정리 :**
오늘은 중복 체크 로직의 위치에 대해 고민하고, 서비스 계층에서만 처리하도록 리팩토링을 완료하였습니다.
**오늘 공부한 토픽:** `서비스 계층 책임`, `중복 체크 리팩토링`
### 1. 중복 체크 중복 문제
- 기존 코드에서는 **서비스 계층**과 **저장소 계층(Store)**에서 모두 **중복 체크 로직**이 존재했습니다.
- 아래는 중복 체크가 중복되었던 예시입니다.
```java
// Store 계층
@Override
public String create(SocialBoard board) {
Optional.ofNullable(boardMap.get(board.getId()))
.ifPresent(targetBoard -> {
throw new MemberDuplicationException("Member already exists with email: " + board.getId()); //+ BoardDuplicationException으로 바뀌어야 함
});
// ...
}
// Service 계층
@Override
public String register(BoardDto boardDto) {
String boardId = boardDto.getId();
Optional.ofNullable(boardStore.retrieve(boardId))
.ifPresent(boardFound -> {
throw new BoardDuplicationException("Board already exists in the club --> " + boardFound.getName());
});
// ...
}
```
### 2. 리팩토링 방향 및 이유
- 중복 체크 로직은 **서비스 계층에서만 수행**하도록 변경하였습니다.
- 그 이유는 서비스 계층이 비즈니스 로직을 담당하는데,
- 중복체크가 단순히 데이터가 있는지 없는지 조회하는 것을 넘어서, **"이미 존재하면 등록할 수 없다"**는 **비즈니스 규칙에 해당**하기 때문입니다. 즉, 단순한 데이터 조회가 아니라 **어떻게 동작할지를 결정하는 로직**이기 때문입니다.