Service와 Entity 비즈니스 로직에 관해

안녕하세요. teamhide님

1. 중복 회원 검증 코드는 비즈니스 로직이라고 봐야할까요?

-> 네 비즈니스 로직입니다.

2. 맞다면 비즈니스 로직은 엔티티에 들어가야 하지 않나요?

-> 서비스, 엔티티 둘다 비즈니스 로직을 처리할 수 있습니다.

3. 요구사항에는 중복 검증뿐만 아니라 수많은 검증 로직들이 존재할텐데, 이를 서비스에 작성해야할지 엔티티에 작성해야할지 어떠한 기준으로 판단해야할까요?

-> 엔티티 한곳에서 처리가 가능하면 엔티티가 처리하면 됩니다. 그런데 엔티티 하나에서 처리할 수 있는 범위를 넘어가면 서비스에서 협업이 필요합니다.

예제에서는 DDD를 꼭 따르는 것이 아니기 때문에 서비스에서 처리했습니다.

이 부분은 조금씩 균형을 잡아가야 합니다. 엔티티에서 처리가 가능하다고 해도 모든 로직은 엔티티에 다 넣으면 엔티티 자체가 복잡해질 수 있습니다. 관련해서 클린코드 책 6장의 객체와 자료 구조를 읽어보시면 관련된 고민을 하는데 도움이 되실거에요.

4. 도메인(엔티티)에서는 레포지토리를 호출하면 안된다고 알고 있습니다. 현업에서는 이를 명확하게 지키면서 코드를 작성하나요?

-> 보통 엔티티에서 리포지토리를 호출하지는 않습니다.

5. 만약 4번이 맞다면, 중복 회원 검증의 경우 실제 데이터베이스에 조회하는 쿼리를 날려야합니다. 이렇게 데이터베이스에 접근해야하는 로직의 경우 엔티티에 작성하면 안되는걸까요?

-> 이 부분은 엔티티에서 리포지토리를 호출하지 않기 때문에 크게 고민하지 않으셔도 됩니다.

감사합니다.

그렇군요!

(3번 답변은 잠깐 넣어두고 최대한 엔티티에 비즈니스 로직을 모아 응집력을 높이려고 한다고 가정했을 때) 그렇다면 말씀해주신 4번에 따라 infra레이어(레포지토리)를 호출해서 무언가 값을 가져와서 비교해야하는 로직의 경우 비즈니스 로직이라고 하더라도 엔티티가 아닌 서비스레이어에 위치할 수 밖에 없는 경우라고 생각해도 될까요?