Service와 Domain의 비즈니스 로직

처음에는 비즈니스 로직을 담당하는 것이 Service라고 배웠다. 하지만 더 학습할수록 Service는 최대한 얇게 구성해야 하며, Domain의 몸집을 뿔려야 한다고 한다.

왜 Service는 얇아져야 하며, 어디까지 Domain에 담아내야 하는 걸까?

비즈니스 로직의 영역 구분

우선 "어디까지 비즈니스 로직으로 봐야 하는가?"부터 보려고 한다.

예를 들어, 김영한님의 JPA1 강의에서는 "중복 회원 검증" 로직은 비즈니스 로직으로 판단되지만 이 것이 Service에 담겼다. Domain에 담는 것은 어땠을까? 하는 고민을 하면서 시작한다.

이 것에 대하여 나와 비슷한 고민을 했던 사람이 질문을 올렸고, 김영한님께서 친절한 답변을 남겨주셨다. 해당 답변을 정리해보면 다음과 같다.

• "중복 회원 검증"은 비즈니스 로직이 맞다.
• 비즈니스 로직은 Service, Domain 모두 처리할 수 있다.
• 만약 엔티티 한 곳에서 처리가 가능하다면 Domain에서 하는 것이 더 좋을 수 있다. 하지만 엔티티 하나에서 처리할 수 있는 범위를 넘어간다면 Service로 넘겨서 협업을 해야 한다.
• 주의할 점은, 엔티티에서 처리가 가능한 문제라 할지라도 모든 로직을 엔티티에 다 넣어버리면 엔티티가 너무 복잡해질 수 있다. (클린코드 6장. 객체와 자료 구조 참고)
• 일반적으로 분명하게, Domain에서는 레포지토리를 호출하진 않는다.
• 위 내용을 종합할 때, 만약 레포지토리를 통해 DB에서 데이터를 가져와 비교해야 하는 로직이 필요하다면 이는 Domain레벨이 아닌 Service에서 수행하는 것이 적절할 것이다.

첨부. 클린 코드 정리 블로그