작성한 질문수 4

3

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

0

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

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

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

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

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

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

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

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

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