작성
·
964
3
DDD 자료를 찾아보면 강의 자료와 같이 Domain이 전체 레이어를 아우르고, Controller에서 Repository를 접근 하도록 설계되어 있습니다.
기초 강의에서는 Entity를 Controller에 넘기지 말라고 말씀 하셨고 그 이유도 충분히 이해 했었습니다.
지금 예제에서는 Controller가 Repository를 호출하게 된다면 Entity가 넘어가게 될텐데... 강의상 편의를 위해서 하신건가요? 실무에서도 빈번하게 사용하는 구조인가요?
추가적으로 DTO를 사용한다면, 아래 예제 계층에서 오고가는 DTO에 대한 표현(naming rule, suffix, package 등등)을 어떻게 하시는지 궁금합니다.
- web <-> controller
- service <-> repository
답변 2
5
안녕하세요. 챕스틱님^^
제가 말씀드린 내용을 정확하게 다시 풀어드리면, 엔티티를 컨트롤러에서 사용해도 되지만, 컨트롤러에서 리턴을 해서 API를 만들 때 엔티티를 사용하지 말라는 의미입니다.
스프링에서 @ResponseBody를 사용하면서 엔티티 자체를 넘기면 바로 엔티티를 API로 반환할 수 있는데, 이것을 하지 말라는 의미입니다.(활용2편에서 더 자세히 예제로 설명합니다^^)
엔티티는 우리 프로젝트의 핵심 도메인이기 때문에 모든 곳에서 접근해도 됩니다. 물론 프로젝트 아키텍처를 어떻게 설계하는가에 따라서 정말 컨트롤러에서 엔티티를 사용하지 못하게 설계하는 방법도 있습니다.
DTO에 대한 표현은 딱 따로 잡는 것은 없습니다^^ 대신에 DTO를 만들때 가장 주의해야 할 점은 페키지 의존관계 입니다. 이 DTO를 어디에서 사용하는가 보고, DTO의 위치를 잡아야 합니다. 예를 들어서 repository까지 사용하는 DTO이면 repository와 같은 위치에 두던가 그 근처에 두어야지, DTO를 컨트롤러나 서비스 패키지에 위치하도록 두면 안됩니다.
감사합니다.
1