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

안녕하세요, kamser님! :)

하나씩 답변 드리겠습니다 ㅎㅎ

전제 : 확장할 일도 없고, 이 서비스는 해당 컨트롤러에서만 사용하게 되는 구조일 경우
Service용 Dto를 만들지 않고 Controller Dto에서
Entity로 변환해서 Service에 넣어주시나요 ?
아니면 코드의 일관성을 생각해서 몇분 안걸리니까 만들어서 사용하시나요?

보통 모듈 분리를 고려하면, 한 두개의 Service만 분리하는 것이 아니라 Service 전체를 모듈로 분리하거나 하게 될 텐데요, 결국은 같은 레이어에 있는 서비스들이 동일한 형태를 갖추지 않는다면 수정 포인트가 될 수밖에 없습니다.

그리고 Entity 이야기가 나와서 말인데, Controller에는 Entity를 노출하지 않는 것이 좋습니다.
여러가지 이유가 있지만, 엄연히 비즈니스 로직의 시작은 서비스 레이어부터고, 조작의 여지, 트랜잭션 등 문제가 될 수 있는 지점이 많아집니다.

서비스 패키지는 도메인 패키지쪽으로 넣어서
api (controller,advice,advice dto),
domain( entity(entity,repository), service(service,dto))
같은 구조로 변경을 하시는지 궁금합니다.

그리고 현재 프로젝트에서 api 패키지 안에 service 패키지를 넣으신 이유도 궁금합니다. !!

도메인과 서비스는 구분을 하는 편입니다.
우리가 만들어가는 소프트웨어의 핵심 비즈니스 로직을 담고 있는 도메인 객체들과, 이를 이용하여 비즈니스 로직을 전개하는 서비스 레이어는 성격이 다르다고 봐서요.
물론 서비스 레이어도 핵심 비즈니스 로직을 담고 있지만, 그렇다고 도메인 패키지 내에 서비스가 들어가기에는 무리가 있다고 생각합니다.

api 패키지를 최상위 패키지로 잡은 건 특별한 이유는 없고요 ㅎㅎ
단순하게 'API를 제공하는 모듈이다' 라는 의미였습니다. (멀티모듈 구조였으면 API 모듈, batch 모듈 등 여러 모듈이 존재했을테니까요)

도움이 되셨기를 바랍니다.
감사합니다. :)

안녕하세요, 인프런 AI 인턴이에요.

첫 번째 질문에 대해서는, 컨트롤러에서만 사용되는 서비스의 경우에는 Service용 Dto를 만들지 않고 Controller Dto에서 Entity로 변환해서 Service에 넣어주시는 것이 가능합니다. 이는 코드 일관성과 개발 효율성을 고려하여 선택하시면 됩니다.

두 번째 질문에 대해서는, 서비스가 확장되고 모듈화되어 사용되거나 다른 컨트롤러에서도 사용될 경우에는 Service 패키지를 도메인 패키지 영역으로 이동시키는 것이 좋습니다. 즉, 해당 서비스의 역할과 책임에 따라 패키지 구조를 재구성하는게 좋을 수 있습니다. 보다 구체적인 변경 방식은 프로젝트의 구조와 요구사항에 따라 다를 수 있으므로, 상황에 맞게 패키지 구조를 조정하는 것이 바람직합니다.

더 자세한 내용을 질문하시려면 코드 예제 또는 프로젝트 구조에 대한 정보가 필요할 수 있습니다. 이에 대한 추가 정보가 있다면 함께 알려주시면 더욱 도움을 드릴 수 있을 것 같아요. 어떤 도움이 필요하신가요?