작성
·
2.8K
12
안녕하세요.
DDD Start라는 책을 함께 읽으며 영한님의 강좌를 다시 한번 보고 있습니다.
그러던 도중 과연 어디까지 비즈니스 로직으로 보아야할까에 대한 의문점이 생겼습니다.
책에서는 도메인(엔티티) 쪽에 비즈니스 로직을 두고 서비스 레이어는 각 도메인의 함수를 호출하는 형태로 구현하여 서비스를 최대한 얇게 만들어야한다고 하더라구요.
그런데 이번 강의 2분 49초쯤을 보면 중복 회원을 검증하는 코드가 서비스 레이어에 위치해있습니다.
회원가입이라는 기능에서 중복 회원 검증이라는 규칙은 서비스에 있어 핵심 비즈니스 로직이라고 생각하는데요.
이 부분을 엔티티쪽에 두어 검증하지않고 서비스 레이어에 두셔서 혼란이 오더라구요.
질문을 요약하자면,
1. 중복 회원 검증 코드는 비즈니스 로직이라고 봐야할까요?
2. 맞다면 비즈니스 로직은 엔티티에 들어가야 하지 않나요?
3. 요구사항에는 중복 검증뿐만 아니라 수많은 검증 로직들이 존재할텐데, 이를 서비스에 작성해야할지 엔티티에 작성해야할지 어떠한 기준으로 판단해야할까요?
4. 도메인(엔티티)에서는 레포지토리를 호출하면 안된다고 알고 있습니다. 현업에서는 이를 명확하게 지키면서 코드를 작성하나요?
5. 만약 4번이 맞다면, 중복 회원 검증의 경우 실제 데이터베이스에 조회하는 쿼리를 날려야합니다. 이렇게 데이터베이스에 접근해야하는 로직의 경우 엔티티에 작성하면 안되는걸까요?
(모든 질문은 DDD를 기반으로 질문드립니다!)
많은 예제들을 살펴보아도 서비스레이어에 작성할지 엔티티쪽에 작성할지 기준을 잡기가 정말 힘드네요..
이 부분에 대해서 영한님의 의견을 듣고 싶습니다.
감사합니다 :)
답변 2
6
안녕하세요. teamhide님
1. 중복 회원 검증 코드는 비즈니스 로직이라고 봐야할까요?
-> 네 비즈니스 로직입니다.
2. 맞다면 비즈니스 로직은 엔티티에 들어가야 하지 않나요?
-> 서비스, 엔티티 둘다 비즈니스 로직을 처리할 수 있습니다.
3. 요구사항에는 중복 검증뿐만 아니라 수많은 검증 로직들이 존재할텐데, 이를 서비스에 작성해야할지 엔티티에 작성해야할지 어떠한 기준으로 판단해야할까요?
-> 엔티티 한곳에서 처리가 가능하면 엔티티가 처리하면 됩니다. 그런데 엔티티 하나에서 처리할 수 있는 범위를 넘어가면 서비스에서 협업이 필요합니다.
예제에서는 DDD를 꼭 따르는 것이 아니기 때문에 서비스에서 처리했습니다.
이 부분은 조금씩 균형을 잡아가야 합니다. 엔티티에서 처리가 가능하다고 해도 모든 로직은 엔티티에 다 넣으면 엔티티 자체가 복잡해질 수 있습니다. 관련해서 클린코드 책 6장의 객체와 자료 구조를 읽어보시면 관련된 고민을 하는데 도움이 되실거에요.
4. 도메인(엔티티)에서는 레포지토리를 호출하면 안된다고 알고 있습니다. 현업에서는 이를 명확하게 지키면서 코드를 작성하나요?
-> 보통 엔티티에서 리포지토리를 호출하지는 않습니다.
5. 만약 4번이 맞다면, 중복 회원 검증의 경우 실제 데이터베이스에 조회하는 쿼리를 날려야합니다. 이렇게 데이터베이스에 접근해야하는 로직의 경우 엔티티에 작성하면 안되는걸까요?
-> 이 부분은 엔티티에서 리포지토리를 호출하지 않기 때문에 크게 고민하지 않으셔도 됩니다.
감사합니다.
네 그것이 여러 엔티티가 될 수도 있고, 다른 서비스가 될 수도 있고 리포지토리의 결과인 엔티티나 DTO가 될 수 도 있습니다.
감사합니다.