도메인 객체 / entity 객체 / requset, response 객체 간 mapping 시 mapper 사용

Question

안녕하세요. 관련 내용을 듣다가 궁금한 것이 생겨 질문드립니다. 해당 강의를 듣다가 궁금한 것이 생겨 질문드립니다. 찾아보니 DDD나 헥사고날 아키텍처에서 request / response 객체 <-> 도메인 객체 <-> entity 객체 간의 mapping이 일어나는 것을 볼 수 있는데요.. 이런 경우 controller, service, infral layer가 모두 mapper 관련 라이브러리 객체나 직접 구현한 mapper 객체를 들고 변환시켜주는 구조는 별로 좋지 못한 구조일까요? 제 개인적인 의견으로는 결국 지금 구조에서 response / request 객체나 entitiy 객체가 domain 객체로 변환시켜주기위해 domain 객체에 의존성이 생기는 구조인데 mapper 객체를 쓰면 이런 객체간의 의존성을 최소화시킨다는 점에서 장점이 있을 것 같은데요.. 물론 정답은 없겠지만, 의견이 어떠신지 궁금하여 질문드립니다.

communityai8509 · Answer

안녕하세요, 인프런 AI 인턴입니다. 질문해주신 내용이 매우 흥미롭네요. 객체 간의 매핑과 관련된 의존성 문제는 소프트웨어 설계에서 중요한 고려 사항 중 하나입니다. DDD나 헥사고날 아키텍처를 채택함으로써 레이어 간의 철저한 분리와 책임의 명확화를 지향하는 것은 맞으며, 이 경우 매퍼 역할이 중요해집니다. 매퍼를 사용하는 구조가 별로 좋지 않은 구조라고 단정 지을 수는 없습니다. 실제로 각 레이어와 객체 간의 변환을 명확하게 하여, 관심사의 분리를 더욱 촉진하고 유지보수성을 향상시킬 수 있는 장점이 있습니다. 또한, 매퍼를 통해 객체 간의 의존성을 최소화시켜줌으로써 더 유연하고 확장 가능한 설계가 가능해집니다. 하지만 매퍼의 사용이 코드의 복잡성을 증가시키고, 런타임 성능에 영향을 줄 수 있다는 단점도 고려되어야 합니다. 따라서 구체적인 프로젝트의 요구사항, 팀의 기술 스택과 선호도, 유지보수의 용이성 등 여러 요소를 고려하여 최적의 접근 방식을 결정하는 것이 중요합니다. 즉, 올바른 매퍼 사용이 소프트웨어의 아키텍처를 더욱 견고하게 만들고 유지보수를 용이하게 할 수 있음에도 불구하고, 그 사용을 결정할 때는 신중한 고려가 필요합니다. 박정선님의 팀과 프로젝트에 가장 적합한 방법을 선택하시길 바랍니다.