인프런 커뮤니티 질문&답변
작성한 질문수
레이어드 아키텍쳐에 대해 질문 드립니다
작성
·
302
0
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.
1. 강의 내용과 관련된 질문을 남겨주세요.
2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.
(자주 하는 질문 링크: https://bit.ly/3fX6ygx)
3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.
(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.
=========================================
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예/아니오)
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)
[질문 내용]
보통 spring mvc 구조에서
View -> Controller -> Service -> Repository로 구성되어있는데, 여기서 Dto 변환하는 곳에서 고민이 있었습니다.
Dto를 Service까지 끌고 가서, Service에서 엔티티로 변환 과정을 거칠것인지. 아니면 Controller단에서 dto - Entity 변환 과정을 거칠것인지 고민이 있었습니다
Service 단에서 변환 과정을 거치게 된다면, 즉 파라미터로 해당 컨트롤러 한곳만 종속적이게 되는 고민이 있게 되었습니다. Service는 여러곳에서도 쓸 수 있다는건데, Dto를 Service 까지 끌고 오게 되면, 매번 서비스 메소드를 만들어야 하는 문제가 있습니다.
그래서 Controller와 Service 사이에
Controller -> Business(Service) -> Service 라는 비즈니스를 추가하여 설계를 하였습니다
Business : dto - entity 변환 로직 처리. 컨트롤러와 상호작용하여 , dto를 받아 entity로 변환 다시 dto를 반환하도록 만들었고, 여기서는 여러 Service의 메소드를 가져와서 복잡한 비즈니스 로직을 처리하도록 하였습니다.
Service : Entity를 받고 Entity를 반환하면, 순전히 해당 도메인의 비즈니스 로직으로만 구성하도록 하였습니다.
이런 식으로 했더니, 좀 더 유연하게 비즈니스 로직을 처리할 수 있더라구요.
제가 설계한 레이어 아키텍쳐 (dto 변환)이 맞는 설계인지, 이렇게도 실무에서 구성하는지 궁금합니다.
답변 2
1
안녕하세요. 두잇베스트님, 공식 서포터즈 y2gcoder입니다.
단순 dto 변환을 위해 Business 계층을 따로 두신 것이 아니라 여러 서비스에 의존해서 좀 더 복잡한 로직을 처리하기 위해 Business 계층을 두셨다면 충분히 실무에서도 그렇게 사용하는 것 같습니다. 개인적으로는 파사드 패턴(링크)의 의도로 사용하고 계신다고 생각이 들고, 충분히 유의미하고 멋진 방식이라고 생각합니다.
다만 dto를 entity로 변환하는 부분에 대해서는 좀 더 생각해볼 여지가 있을 것 같습니다. 어떤 service의 a() 메서드의 요청 파라미터로 사용할 aDto를 만들었다면 컨트롤러계층에서 해당 메서드를 호출할 때 요청 파라미터를 aDto로 변환 후 a()에 넣어 호출하는 식으로 하면 해당 메서드를 재사용할 수 있다고 생각합니다. 서비스에서는 해당 dto를 비즈니스 로직에 따라 처리하면서 엔티티로 바꾸거나 등의 처리를 할 수 있을 것 같습니다.
그리고 이러한 것보다 중요한 것은 영한님께서도 누누이 말씀하시는 순환 의존을 제거하는 것이라 생각합니다. service 계층에서 사용하는 dto라면 controller 계층에서 사용할 수는 있으나 반대로 controller 계층의 dto는 service 계층에서는 사용하지 않도록 하는 것을 대원칙으로 해서 의존 방향만 단방향으로 유지해줘도 유지보수하고 변경하는데 큰 무리는 없었습니다.
감사합니다.
controller -> service -> repository 계층으로의 단방향 의존을 잘 지켜주면 된다는 의도를 전달해드리려고 예시를 든게 더 혼동이 온 것 같습니다... 죄송합니다.
아닙니다 !!
좀더 질문드려봅니다. 단방향 의존이라는게
보통 Controller에서 Service를 의존하지만, Service에서 Controller를 의존하지 않듯이
이런 대원칙만 지키면 된다는 말씀이신가요?? service에서 dto를 변경하더라도
0
안녕하세요, 인프런 AI 인턴입니다.
DTO 변환 위치에 대한 고민과 Service 계층의 책임 범위에 대해 질문하셨네요. 이와 유사한 내용으로 진행된 이전의 토론을 참고하시면 좋을 것 같습니다.
관련된 게시글을 찾아보니, DTO 변환과 관련하여 Service 계층과 Controller 계층 사이에 비즈니스 로직 처리를 위한 별도의 계층을 두는 방법에 대해 논의한 내용이 있습니다.
이전에 질문한 수강생님도 비슷한 고민을 하신 적이 있으며, 여기에 대한 다양한 답변과 실제 현업에서의 적용 사례 등을 찾아보실 수 있습니다. 아래 링크의 내용을 확인해보시는 것을 추천드립니다.
각 링크에서는 Service 계층과 Controller 계층 사이에서 DTO와 Entity의 변환을 어떻게 처리하는 것이 좋은지에 대한 토론이 이루어졌습니다. 여러 방법 중 하나로, Business 계층을 두어 DTO 변환을 담당하게 하는 방법이 언급되어 있으니 참고하시면 도움이 될 것입니다.
감사합니다.
"그리고 이러한 것보다 중요한 것은 영한님께서도 누누이 말씀하시는 순환 의존을 제거하는 것이라 생각합니다. service 계층에서 사용하는 dto라면 controller 계층에서 사용할 수는 있으나 반대로 controller 계층의 dto는 service 계층에서는 사용하지 않도록 하는 것을 대원칙으로 해서 의존 방향만 단방향으로 유지해줘도 유지보수하고 변경하는데 큰 무리는 없었습니다."
이 부분에 대해서 이해가 되질 않아 좀 더 질문드려봅니다.
순환 의존을 제거하라는 의미가
Controller에서 ADto를 받고 -> Service bMethod(ADto)<< dto가 양쪽에서 의존하는 다음과 같은 코드를 하지말라는 말씀인가요?