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

안녕하세요 질문 감사합니다!
질문이 좀 산개 되어있어서 😅 하나씩 정리해서 답변드리겠습니다!

[질문1]

적어주신 내용들 보다는 개념간의 적절한 격벽 구성을 유지하며 가장 쉽게 요구사항을 구현하는 목적을 달성하기 위한 전략 중 하나를 적용하였다고 봐주시면 됩니다

+ 추가로 기존 질문과 유사한 느낌의 질문이 있어서 링크 첨부 드립니다!

위의 링크드린 질문 답변에도 있지만 이 방식이 제가 선호하는 구현 방식은 아닙니다
그저 지금 상황과 규모에 맞는 적절한 구현 전략을 선택한 예시를 보여드리고 생각을 해보시게 만들어드리고 싶었습니다 😃

++ 트랜잭션에 대해서는 추가로 적어두면 Service 하나에 트랜잭션 하나로 묶는 것은 경우에 따라 역으로 비효율이 발생할 수 있습니다 (너무 길고 큰 트랜잭션일 경우 + 내부에서 외부 통신으로 Tran 시간이 길어지고 커넥션을 과소비하는 등)
그래서 이것 자체가 트레이드 오프가 될 수 있다고 봅니다,
개인적으로 저는 Service 함수에 Transaction을 무조건 or 쉽게 거는 것을 선호하지는 않습니다!
(그래서 Controller 에서 이 구조와 Transaction은 크게 관여가 없는 전략이라고 봐주셔도 될 것 같습니다! 또 우리 강의 예제 규모에서는 신경쓸 수준이 아니라고 보여지구요!)

[질문2]

유즈케이스 라는 관점으로 봐도 크게 문제는 없을 것 같은데요! 지금 강의 기준으론 각각의 개념이 요구사항을 충족하기 위한 기능을 제공하고 있는 것이라고 이해해주시면 될 것 같습니다!
사실 이 강의 규모에서는 잘 정리된 느낌의 유즈케이스라던가, Aggregation이라던가 를 논하기엔 너무작은 규모+혼란스러운+요구사항이 너무 빈약한형태라 생각합니다 😃

가령 ProducSectionService 함수 하나를 유즈케이스로 보기엔 미묘한 부분이 있다고 봅니다

[질문3]

일단 제가 바라보는 기준과 구현 전략에서는 대부분의 경우 Service 에서 다른 Service 를 호출하게 하지 않습니다

위의 유사 질문의 답변에도 있지만 저는 방법1,2 둘다 아닌 Service -> 구현을 위한 도구들을 호출하는 방식으로 작업하는 것을 선호합니다 (당연히 무조건은 아니고 대부분의 경우입니다)

이것 관련해서는 지속 성장 가능한 소프트웨어를 만들어가는 방법 이라는 제가 작성한 블로그 글과 인프런 무료강의 가 있으니 궁금하시면 봐보셔도 좋을 것 같습니다!

++ 추가로 어느 정도 규모의 서비스를 운영중이신지는 제가 잘 몰라서 조심스럽지만 제 의견을 적어보면
모듈별이라는 의미가 만약 멀티모듈의 모듈이라면 조금 과한 구조가 아닐까 싶단 생각이 들었습니다!

제가 상상하는 구조라면 적절한 응집이 구성되지 않은 형태일 것 같이 느껴집니다 🤔
(이건 제가 상황을 잘 모르고 한 말이니 그냥 지금 제가 가진 정보 기준의 잘 모르는 사람이 말하는 느낌이라 봐주시면 될 것 같습니다 😃 아니라면 참 다행이에요!)

추가적으로 질문 주신 것들에 대한 의도와 느낌과 고민은 뒷 강의들을 들으시다보면 더 혼란을 느끼시면서 생각이 정리 되실 수 있을 것 같습니다, 종류별로 구현체를 뒤죽박죽 해두었거든요! 😃

모쪼록 시작하시는 시점에 혼란을 충분히 느끼고 계신데 아주 좋다고 봅니다!
지금 상태에서 약간이나마 답이 되었길 바라며 완강까지 화이팅입니다!
추가 질문이 있다면 편하게 주시길 바랍니다!