하위 레이어가 상위 레이어를 알고 있는 경우에 대해 질문 있습니다.
166
작성한 질문수 57
안녕하세요.
하위 레이어가 상위 레이어를 알고 있는 경우는 좋지 않다고 하셨는데
만약에 도메인을 순수하게 유지하고 싶어서
도메인 엔티티와 jpa 엔티티를 분리하고, service와 jpaRepository에 DIP를 적용하게 되면
service에서는 repository 인터페이스를 사용하고,
repository 인터페이스를 구현하는 repositoryImpl에서 jpaRepository를 사용하게 될 것 같습니다.
이 경우에 repositoryImpl에서는 jpa 엔티티 -> 도메인 엔티티로 변환을 하고, 도메인 엔티티를 service로 반환해주어야 할 것 같은데
이렇게 되면 하위 레이어인 infrastructure(persistance) 레이어에서 상위 레이어에 있는 도메인 엔티티에 대한 의존성이 생긴다고 생각하는데 이런 경우는 상위 레이어에 의존성이 생겨도 상관 없는 경우인가요??
테스트 강의와 무관한 질문을 드려서 죄송합니다 ㅠㅠ
답변 2
1
안녕하세요, eoyeong 님!
정확히는, 도메인 엔티티를 Infrastructure layer에서 알고 있다는 것이 문제가 아니라, 의존성 방향이 잘 설정되었는지가 주요한 내용입니다.
말씀하신 구조는 서비스에서 인프라 레이어의 로직을 알지 못하고, 인터페이스를 통해 참조하는 형태이기 때문에 DIP가 잘 적용되어 있는 구조인데요.
이 때, 인프라 레이어에서 도메인 엔티티를 알고 반환하는 것은 자연스러운 현상입니다. 의존성 방향은 이미 상위 레이어가 하위 레이어에 의존하지 않도록 역전되어 있는 상태이기 때문에 DIP를 위반하는 형태가 아닙니다.
도움이 되셨기를 바랍니다.
감사합니다. 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
ga님께서 질문하신 주제는 백엔드 아키텍처의 설계 원칙 중 하나인 의존성 규칙에 관한 것입니다. 일반적으로, 하위 레이어가 상위 레이어를 알게 되는 것은 좋지 않다고 여겨집니다. 이는 상위 레이어의 변화가 하위 레이어에 직접적인 영향을 미치기 때문입니다.
하지만, 특정한 시나리오에서는 하위 레이어에서 상위 레이어의 도메인 엔티티를 사용할 수 있습니다. 특히, 도메인을 순수하게 유지하고, 인프라스트럭처 레이어에서 비즈니스 도메인을 처리해야 할 경우에 그렇습니다. 이러한 경우, 아래와 같은 방법을 고려할 수 있습니다:
역할과 책임의 분리: 하위 레이어가 상위 레이어의 도메인 개념을 이용해야 할 경우, 상위 레이어의 인터페이스를 통해 간접적으로 상호작용하도록 설계할 수 있습니다. 이를 통해 하위 레이어는 상위 레이어의 자세한 구현을 알 필요가 없습니다.
DTO를 이용한 변환: JPA 엔티티와 도메인 엔티티의 변환을 할 때는, 중간에 DTO(Data Transfer Object)를 사용하여 레이어 간 데이터 전송을 명확히 할 수 있습니다. 이를 통해 레이어 간의 결합도를 낮추고, 상호작용을 명확히 할 수 있습니다.
변환 로직의 중앙 집중화: 만약 변환이 불가피하다면, 변환 로직을 레이어 외부의 별도 모듈로 축출하여 관리할 수 있습니다. 이렇게 하면 변환 로직 자체의 독립성을 확보할 수 있습니다.
결론적으로, 의존성이 생기는 것을 완전히 배제할 수는 없으나, 그 의존성을 관리하고 최소화하는 방향으로 설계하는 것이 중요합니다. 이를 통해 레이어 간의 변경 영향도를 줄이고, 시스템의 유지보수성을 높일 수 있습니다.
강의를 통해 테스트에 대한 많은 인사이트를 얻으셨기를 바랍니다. 추가 질문이 있으시면 언제든지 말씀해주세요!
출처:
- Spring Data JPA - Reference Documentation
- Spring Data JDBC - Reference Documentation
private 상수 테스트 관련 질문
0
82
1
void는 어떻게 테스트하나요..? void로 애초에 코딩하면 안되나요??
0
124
2
커버리지는 어떻게 활용하시는지 궁금합니다.
0
159
2
테스트 문서화 질문입니다
0
104
2
단위테스트 질문이 있습니다
0
94
2
컨트롤러는 모킹을 한 이유가 궁금합니다.
0
100
2
ERD 가장자리에 있는 도메인 테스트 질문
0
87
2
DTO 검증 필드에 대한 테스트 코드 작성은 어디까지?
0
132
2
OrderCreateRequest DTO에 대해서 궁금한점
0
101
2
고전파의 테스트 대역 사용 대상, 공유 의존성
0
154
2
계층 관련 질문이 있습니다.
0
137
3
'코틀린'에서는 빌더를 따로 쓰지 않는데, 이 때는 어떻게 test fixture를 만드시는지 궁금합니다
1
122
2
혹시 update 로직은 어떻게 테스트하나요? (@Setter?)
0
133
2
단위테스트와 통합테스트의 경계가 궁금합니다.
0
227
2
Service+Repository 통합테스트 관련 질문입니다.
0
149
2
OrderControllerDocsTest 작성 해봤는데요. 날짜 형식이 이상하게 나와요
0
183
2
test 용 .yml
0
89
2
throws Exception
0
78
2
카페키오스크 클래스 문의 ,,
0
87
2
Rest docs 문서용 테스트코드를 따로 작성해야 되나요?
0
171
2
테스트 코드에서 필요한 생성자
0
137
1
tearDown 순서
0
115
2
@Builder 생성자 private
0
135
2
@DisplayName gradle / intellJ
0
92
2





