작성
·
123
0
안녕하세요.
하위 레이어가 상위 레이어를 알고 있는 경우는 좋지 않다고 하셨는데
만약에 도메인을 순수하게 유지하고 싶어서
도메인 엔티티와 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
답변 감사합니다 :)