2부 마지막 리팩토링 3:30쯤
262
작성한 질문수 22
2부 마지막 리팩토링 0:49에서, "service인데 controller.port를 잘못 참조했다"라고 하셨는데요.
이를 수정하고 나신 후인 3:30쯤에서도, 여전히
service(의 UserServiceImpl)가 controller(의 Port의 UserService)에 의존하는 상황이지 않나요?
제 생각엔 Port 자체를 controller 밖으로 꺼내는 게 의미상 더 좋지 않을까 싶은데 어떻게 생각하시나요?
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
질문자님께서 말씀하신 부분은 개발 시 아키텍처 설계와 관련된 중요한 부분을 다루고 있습니다. 서비스 레이어가 컨트롤러 레이어에 정의된 포트에 의존하는 것은 일반적으로 바람직하지 않습니다. 이러한 상황은 레이어 간의 역할과 책임이 명확히 구분되지 않음을 의미할 수 있습니다.
Port를 외부로 분리하는 것은 레이어 간의 의존성을 줄이고 시스템의 결합도를 낮추어, 유연하고 확장 가능한 설계를 가능하게 합니다. 이러한 접근 방식은 헥사고날 아키텍처(Hexagonal Architecture) 또는 포트 & 어댑터(Ports & Adapters) 아키텍처 패턴에서 자주 볼 수 있으며, 애플리케이션의 핵심 로직을 외부 컴포넌트로부터 분리하여 테스트와 유지보수를 용이하게 합니다.
님의 제안대로 Port 인터페이스를 컨트롤러 바깥으로 이동시키고, 이를 통해 서비스가 컨트롤러가 아닌 인터페이스에만 의존하도록 설계를 변경하는 것이 좀 더 깔끔한 구조를 만드는 방법일 수 있습니다. 이렇게 하면 추후 다른 컨트롤러나 어댑터에서도 동일한 서비스를 재사용할 수 있는 유연성을 확보할 수 있습니다.
이와 관련하여 Spring에서는 의존성 주입, @Service 어노테이션과 같은 기능을 통해 이러한 설계 패턴을 잘 지원합니다. 따라서, 개발하시는 도중에 이러한 구조적인 설계 변경을 고려해보시는 것도 좋을 것 같습니다.
UserService, CertificationService 책임 분리 기준 질문
0
28
1
service.port 패키지로 이동한 UserRepository가 infrastructure에 있는 UserEntity에 의존
0
60
1
Service 소형 테스트 질문
0
86
1
조회 시 엔티티를 조회하는 것이 아닌QueryDSL을 많이 사용 시 Dto는 어떻게 하나요?
0
116
1
controller 의 port 패키지의 service 인터페이스 사용
0
73
1
빌드 문제
0
92
1
빌드 안 되시는 분들 참고
0
102
1
update에서 Repository.save
0
105
1
최종 완성된 코드를 받아 볼 수 있을까요?
0
158
1
의존성 역전으로 해결한 외부의존성?
0
166
1
좋은 설계
0
180
1
Controller에 테스트
0
140
1
JPA가 아닌 Mapper 아키텍처 기반 테스트 코드 작성
0
243
0
영속성 객체 구분으로 인한 JPA와 Querydsl의 Projection 사용
0
225
1
인프라계층 구현체와 테스트 구현체에 대한 질문
0
225
1
실습 코드 커밋
0
375
1
UserEntity 메서드
0
295
2
CertificationServiceTest에서 MailSender 인터페이스가 아닌 FakeMailSender를 이용하는 것
0
218
1
레이어드 아키텍처 개발에 대하여
0
232
1
BDDMockito의 when을 사용한 코드가 given 절에 있는 이유가 궁금합니다.
0
223
1
테스트에서 주입과 생성
0
200
1
프로젝트 코드는 제공해주시지 않는건가요?
0
383
2
개선된 아키텍처의 구조
0
277
1
서비스 레이어의 단위 테스트 범위 고민
0
190
1