인프런 커뮤니티 질문&답변

답변 주셔서 감사합니다!

1. 도메인 계층은 강사님께서 말씀해주신 레이어에서 비즈니스 계층과 구현 계층에 있습니다. 또한 비즈니스 로직을 가지고 있는 계층을 의미합니다!

2. 순수한 로직이란.. 제가 생각하기에는 순수 자바코드로만 이루어진 코드라고 생각해요! 그래서 테스트하기에 편하다는 장점이 있는...? 코드인 것 같습니다! 그렇다면 순수하지 않은 로직은... 자바 코드 이외에 코드들이 섞여있는 로직입니다. 예를 들어, Slice 클래스에 Pageable 객체가 있는..? 그런 것 같습니다!

3. 제가 2번에서 말한대로 한다면 순수한 상태인 것 같아요... 잘 모르겠습니다. 하지만 찾아본 결과 인텔리제이에서 Page 클래스를 들어가 확인해봤을 때는 Slice를 상속받고 있던데 Slice 클래스를 보니까 Pageable을 사용하므로 순수하지 않은 상태입니다!

4. int 변수로 page, size 값을 받은 다음에 컨트롤러에서 서비스 호출 후 서비스에서 레포지토리 호출을 할 때, 레포지토리 안에서 Pageable 객체를 만든 다음 JPA에 담아주었습니다!
(예시 : Pageable pageable = PageRequest.of(page, size, Sort.by("id").descending()); )

5. 음... 단순히 Page로 반환만 하면 되는 것을 DTO를 만들어 반환할려니까 순수하게 귀찮습니다... 그리고 Page로 반환되는 값들을 다른 클래스로 일일히 매핑해야되니 일이 2배가 되는 단점이 있습니다!

6. 먼저 서비스에서 JPA 레포지토리를 쓰는 것은 의존이 있는 상태입니다! 근데 순수하다...? 는 아닌 것 같아요! 답변을 쓰다가 생각해보니 JPA 자체가 순수하지 않은 것 같습니다. 왜냐하면 ... 그냥 느낌적인 느낌이랄까요.. 잘 모르겠습니다

답변을 작성하면서 제 자신에게 계속 질문을 던지면서 추가하고 수정하였습니다. 답변이 이상해도 너그러운 이해 부탁드립니다..!

충분히 고민에 빠지신 것 같으니 제 의견을 드리겠습니다!
더 많이 고민해보시고 이것 저것 케이스별로 만들어서 느껴보시기를 권장드립니다!

Page 클래스는 예제코드에서 io.dodn.commerce.core.support.Page 클래스를 말한것 이였습니다 😄

현성님 말대로라면 저 Page 클래스는 순수하게 도메인계층에 존재하는 것이겠네요 (물론 패키지 적으론 support 하위에 있지만요)

OffsetLimit 클래스 (io.dodn.commerce.core.support)는 코드 보면 PageRequest, Pageable 을 알고있네요 그럼 순수하지 않은 상태라고 할 수 있을 것 같습니다

그리고 궁극적으로 Service 클래스들에서 JPA Repository 를 직접적으로 쓰고있는데 이건 순수하지 않은 상태라고 하셨습니다

그러면 이 프로젝트는 결론적으로 순수하지 않은 상태인 것으로 정의 할 수 있을 것 같습니다

그럼 왜 그래야하는 것 일까요?
결국 답은 5번에서 직접 말해주신 부분과 연관이 있는 것 같습니다, 애매하게 순수함을 유지하려고 하는 명목하에 비효율이 존재한다고 생각합니다

추가로 저도 100% 생각하시는 예제가 안그려지지만, 4번에서 답변 주신 것과 겹치면 애초에 도메인 계층이 순수한 상황은 아닐 것 같아요

사실 온전히 순수함을 강조하고 싶다면 구조를 바꾸어야합니다
(이것 관련해서는 이제는 좀 오래 된 영상이지만 제 유튜브 영상을 참고하셔서 느낌만 보셔도 됩니다)

지금 우리 상황의 프로젝트에서는 매일 요구사항이 바뀌고 도메인 정립이 제대로 된 안정적인 상황이 아니라 변경에 대한 빠른 수정과 효율 이 더 중요한 상황입니다.

그런 상황에서는 이 구조가 나쁘지 않은 것이죠

만약 도메인 계층이라는 것을 정의해서 완전히 순수하게 유지하려고한다면 애초에 JPA Repository 의 존재도 모르는 구조로 만들어야합니다 (더 나아가서는 JPA 의존성 조차도 모르게 해야겠지요)

결국 그 구조를 언제 갈 것인가? 는 저는 대부분 경우 항상 늦게 가도 된다고 생각하는 편이긴합니다
(다만 확실성이 있는 플랫폼이나 요구사항과 개념들이 안정된 서비스 개발이라면 바로 이상적인 구조로 갈 수 있다고는 생각합니다)

말이 좀 길었는데 핵심만 요약하면 현재 우리 상황에서 Paging에 대한 의존이나 순수함을 지켜주는 것은 큰 이점은 없습니다.

이미 spring-data(/w JPA)에 대해서는 의존하는 것을 기본으로 하였기 때문입니다.
(코드 보시면 Entity 도 직접적으로 쓰고 있죠)

실제 대부분 회사에서는 이런 기본적인 구조 선택이 이미 되어있는 경우가 많습니다
(그 선택 기준은 단순히 멋진 개발 기준으로만 이루어지지 않을 수도 있구요, 현실적인 이유가 많이 들어가있겠죠)

그래서 개인적으론 마냥 클린아키텍처나 헥사고날이나 이런 것에 기준을 가두시기 보다 다양한 관점으로 이 구조의 장/단점 왜 이런 선택을 했을지를 고민해보시면 좋을 것 같습니다

저 또한 그러셨으면 좋겠어서, 생각을 더욱 자극시켜드리고자 고민되시게 예제를 구성한 의도도 있습니다 😄

[짧은 답변]

• 단순한 트레이드 오프일까요?

  • 사실 이건 단순하지 않습니다, 회사의 개발 문화와 전략 수준의 복잡한 트레이드 오프입니다.

  • 최악의 경우(어쩌면 대부분 회사..)는 정해진 기준도 없을 수 있습니다, 프로젝트 마다 구조와 기준이 다르죠

• 클린 아키텍처와 회사 내 규칙을 따를 것이냐 아니면 개발 편의성을 위해 Page만 허락한다는 등... 그런 것들이 존재할까요?

  • 존재 할 수 있습니다, 다만 Page만 처럼 일부만 예외를 두는 전략은 회사에서 대부분 혼란을 만들기 때문에 저는 선호하지 않습니다 (구전 동화가 되버립니다)

  • 아예 전부 열거나/닫거나 이 방향이 언제나 기존/신규 팀원 모두 이해하기 쉬워지는 것이죠

• 그렇지만 도메인 계층에서 스프링 프레임워크에 대한 의존성을 갖는게 되지 않을까요...

  • 이것은 위에도 설명드리고 답변 적으시면서 느끼셨겠지만, 스프링 의존을 완전히 빼려면 기본적으로 구조 자체가 바뀌어야합니다

  • 그럼 일부만 빼는 방법도 있긴한데요, 위에도 말했지만 애매하게 일부만 빼는 것은 제 경험상 사람이 바뀌고, 새로운 사람이 오고 등등 어떻게든 혼란을 만들었던 것 같습니다

모쪼록 최대한 생각을 많이 해보셨으면해서 주절주절 적었는데 추가로 궁금하신 부분이 있다면 추가 질문 부탁드립니다!