LUMI_dev

1달 역량평가_DailyReport0424 본문

카테고리 없음

1달 역량평가_DailyReport0424

luminous_dev 2025. 4. 28. 08:21

**오늘 날짜 :** 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. 리팩토링 방향 및 이유

- 중복 체크 로직은 **서비스 계층에서만 수행**하도록 변경하였습니다.
    
- 그 이유는 서비스 계층이 비즈니스 로직을 담당하는데,
- 중복체크가 단순히 데이터가 있는지 없는지 조회하는 것을 넘어서, **"이미 존재하면 등록할 수 없다"**는 **비즈니스 규칙에 해당**하기 때문입니다. 즉, 단순한 데이터 조회가 아니라 **어떻게 동작할지를 결정하는 로직**이기 때문입니다.