레이어드 아키텍쳐에 대해 질문 드립니다

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.

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 변환)이 맞는 설계인지, 이렇게도 실무에서 구성하는지 궁금합니다.