작성
·
245
0
강의 열심히 들으며 실습하고 있습니다!
헥사고날 아키텍처를 학습하며 적용해 보니 다양한 어려움이 생기더라구요 ㅠㅠ
혹시 entity 내의 from과 to 메서드조차 분리하고자 할 때 궁금한 점이 생겼습니다.
Entity 내의 from과 to 메서드로 domain ↔ entity를 변환하는 것을 Converter 클래스를 통해 관심사를 분리하는 것이 괜찮은지?
만일 분리한다면, Converter interface의 위치는 domain 하위 port package일지, infrastructure 하위 port를 만들어 사용할지? (Impl 구현체는 따로 패키지를 생성할 예정입니다)
강의 열심히 듣고 보내주신 책도 잘 받아 열심히 공부하고 있습니다 ㅎㅎ
책에 껴주신 Thankyou.java 파일 잘 받았습니다! 감사합니다
답변 2
2
1. mapper 의존성을 추가해서 해당 변환을 대신 해주거나 직접 구현하는 경우가 있습니다. 다만 domain 과 entity 필드가 대부분 일치한다면 entity 에 method 로 작성해서 코드를 줄이는게 더 좋을수도 있습니다.
mapper 의 패키지 위치를 고민해보면 domain 을 다른 무언가로 변환하는 개념으로 infrastructure 에 위치하는게 개념적으로 더 좋은 모양입니다. 그 이유는 domain 하위패키지에 존재한다면 해당 entity 를 domain 이 알아야 한다는 의미이기 때문입니다.
0
안녕하세요, 인프런 AI 인턴입니다.
정보에 언급된 내용과 질문의 내용이 일치하지 않아, 특정 답변을 드릴 수 없음을 양해 부탁드립니다. Montag님의 학습에 도움을 드리고 싶었지만, 주어진 정보 내에서는 관련 내용을 찾을 수 없습니다.
헥사고날 아키텍처와 관련하여 Entity의 from과 to 메서드 분리에 대한 구체적인 가이드는 제공된 정보에 없습니다. 하지만 관심사의 분리 원칙에 따라, 변환 로직을 별도의 클래스로 분리하는 것은 일반적으로 권장되는 접근 방식입니다. Converter 클래서는 관심사를 분리하고 코드의 재사용성을 높이는 데 기여할 수 있습니다.
Converter 인터페이스의 위치에 대해서는, 이를 사용하는 컨텍스트와 가까운 위치에 두어야 합니다. 도메인 → 엔티티 변환 로직이 주로 도메인 계층에서 사용된다면, domain 하위의 port 패키지에 두는 것이 적절할 수 있습니다. 반면, 인프라스트럭처와 관련된 변환 로직이라면, infrastructure 하위에 두는 것이 더 적합할 수 있습니다. 구현체는 각각의 로직이 가장 많이 사용되는 위치에 기반하여 패키지를 결정하시는 것이 좋습니다.
다시 한번, 구체적인 답변을 드리지 못해 죄송합니다. Montag님의 질문에 더 정확하고 유용한 답변을 드리지 못한 점 양해 부탁드립니다.