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

계층간 의존관계를 생각하면 현재 Request로 끝나는 파라미터를 담은 레코드 클래스는 도메인에 있어야 계층형 아키텍처의 의존 관계 규칙을 지킬 수 있습니다. 도메인이 가장 안 쪽이 있기 때문에 자신을 포함해서 외부 계층에서 의존해도 안전합니다. 이걸 다른 계층으로 옮기면 계층간 단방향의 의존관계가 깨집니다.

안녕하세요, 인프런 AI 인턴입니다. 처아미나님께서 주신 질문에 대해 답변드리겠습니다.

DTO(Data Transfer Object) 위치에 대한 고민

MemberInfoUpdateRequest와 MemberRegisterRequest 같은 객체는 주로 데이터 전송을 목적으로 합니다. 이러한 객체의 패키지 위치를 결정하는 데에는 몇 가지 고려할 점이 있습니다:

1. 사용 범위에 따른 패키지 구분: DTO가 사용되는 주요 컨텍스트에 따라 패키지를 결정하는 것이 좋습니다.

   • 도메인 논리 사용: 도메인 내부에서 비즈니스 로직과 밀접하게 연관된 경우, 도메인 패키지에 위치시키는 것이 적절할 수 있습니다.
     
   • 애플리케이션 계층 사용: 요청 데이터가 여러 계층에서 활용된다면, 애플리케이션 계층에 위치시키는 것이 관리 측면에서 유리할 수 있습니다.
     

2. 응집력과 결합도: DTO는 주로 데이터를 담아 여러 계층 간 상호작용을 지원하기 위한 객체입니다. 따라서, 도메인 로직과 강하게 결합되지 않는 한 도메인 패키지에 직접 포함시키는 것이 최적이지 않을 수도 있습니다.

3. 패키지 구조 유연성: 프로젝트의 구조에 따라 DTO의 위치는 유동적일 수 있습니다. 다양한 관점에서 고려하고 팀 내의 컨벤션에 따르는 것이 좋습니다.

관련 내용에 대해 더 자세히 배우고자 한다면 아래의 게시물을 참고해보세요:
- Member의 등록과 수정에 대한 API 설계

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.