-
질문 & 답변
카테고리
-
세부 분야
백엔드
-
해결 여부
해결됨
Uuid의 의존성 주입과 의존성 방향에 대한 질문입니다.
23.09.13 09:13 작성 조회수 283
0
안녕하세요! 강의 너무 잘듣고있습니다.
소스코드 내에서 UuidHolder와 User의 관련 의존성 방향에 대해 질문이 있어 글 남깁니다
public static User from(UserCreate userCreate, UuidHolder uuidHolder) {
return User.builder()
.email(userCreate.getEmail())
.nickname(userCreate.getNickname())
.address(userCreate.getAddress())
.status(UserStatus.PENDING)
.certificationCode(uuidHolder.random())
.build();
}위 코드에서 Parameter값을 통해 User 객체가 UuidHolder 라는 클래스에 의존하게 되는데요. UuidHolder 의 경우 common 패키지의 application layer에 존재하는 것으로 알고 있습니다. Domain layer의 User객체가 application layer의 객체에 의존하는 것이 parameter형태로는 허용이 되는지 질문드립니다.
답변을 작성해보세요.
1
김우근
지식공유자2024.01.28
안녕하세요. 근래에 책을 집필할 기회가 생겨 그쪽에 힘을 실어주다 보니 다른 일에 신경 쓰지 못했습니다. 답변이 늦어 죄송합니다. 다만 해당 강의는 공식적으로 질의응답을 제공하지 않는 강의였다는 점을 이유로 늦어진 부분에 대해 양해 부탁드립니다.
지적해 주신 내용이 맞습니다. parameter 형태로라도 User 클래스가 Application Layer에 의존하게 되는 방향이면 안 됩니다. 그러므로 이는 UuidHolder와 ClockHolder의 위치가 잘못됐다고 평가하는 게 맞을 듯 보입니다. 지금 와서 보니 이 둘은 common/domain에 들어가는 게 더 적합해 보이고요. 변명하자면 강의 중 강박적으로 인터페이스를 port에 넣는 모습을 보여주려다 보니 벌어진 실수 같습니다. 면목 없습니다.
조만간 강의 내용을 수정해야 할 일이 있을 것 같은데, 그때 수정하면서 일부 코드도 리팩토링하겠습니다. 지적 감사합니다!
+) 더불어 제게도 안 좋은 습관이 몇 개 있는데, 코드를 다시 보며 그런 것들이 눈에 많이 밟히네요. (대표적인 실수 중 하나는 패키지 이름을 service라고 적어둔 것입니다. 이는 application 레이어를 뜻한 것이었기 때문에 패키지 이름은 applicaiton이 되는 게 맞습니다.) 민망합니다; 일들이 정리되고 여유가 생기는데로 수정해 보도록 하겠습니다.
1
인프런 AI 인턴
2023.09.14
안녕하세요, 인프런 AI 인턴이에요.
질문 주신 내용에 대해 답변해드리겠습니다.
파라미터를 통해 User 객체가 UuidHolder 클래스에 의존하게 되는 경우, 이는 일반적으로 문제가 되지 않습니다. 드물게는 Domain Layer에서 Application Layer에 직접적으로 의존하는 것이 좋지 않을 수도 있지만, 이 경우에는 User 클래스가 파라미터를 통해 의존 관계를 주입받기 때문에 크게 문제가 되지 않습니다.
UuidHolder 클래스가 Application Layer에 속한다면, User 클래스가 Application Layer에 의존하게 되는 것은 허용되는 의존성 방향입니다. 또한, UuidHolder는 User 클래스를 사용하기 위한 필수 의존성으로 생각할 수 있습니다.
의존성 주입을 통해 의존성을 제어하는 것은 코드의 유지 보수와 테스트에 도움을 줄 수 있는 방법이기 때문에, 현재 코드의 의존성 방향은 합리적인 선택으로 보입니다.
혹시 추가로 궁금한 점이 있으시면 언제든지 물어보세요. 즐거운 개발되세요!
요
답변 2