인프런 커뮤니티 질문&답변

영한님 답변해주셔서 대단히 감사합니다! 
실무에서 JPA를 사용하시는 고수님의 답변을 들으니 큰 힘이 되네요!
걱정하던(찜찜하던) 부분에 대해 설명을 들으니 더 용기가 생기네요 ㅎㅎ
꼭 영한님 JPA  시리즈 강의를 완강하고 실무에서 적용해 보겠습니다!

toDTO를 두면 좋을 것 같지만, 복잡한 상황에서는 사실 크게 효과가 없습니다^^

왜냐하면 사용자에게 보여주어야 하는 화면이나 API에 따라서 다른 PM의 모양을 보여주어야 하는데, 그때마다 toDTO를 계속 다른 모양으로 만들어야 하니까요. 이렇게 되면 화면에서 원하는 DTO가 발생할 때 마다 PM 자체에 toDTO를 만들면서, 결국 PM 자체를 수정해야 하는 문제가 발생합니다.

그래서 보통 선택하는 실용적인 방안이 PM에 getter는 모두 열어두고, setter는 최대한 막는다 입니다.

getter는 데이터를 단순히 조회만 하지, 데이터를 변경하는 것은 아니기 때문에 열어두어도 큰 문제는 없습니다.

그리고 getter가 열려있기 때문에 PM 코드를 손대지 않고 필요한 경우 별도의 DTO를 만들 수 있습니다.

setter는 잘못 호출하면 PM의 데이터 자체가 수정되기 때문에 최대한 닫아두고, 꼭 필요한 경우 의미있는 비즈니스 이름이 담긴 메서드를 사용합니다. 예를 들어서 order.delivery(xx)... 하나를 변경해야 하면 changeXxx(xxx) 등등을 사용합니다.

사실 PM, DM을 분리해서 사용하는 경우는 거의 없기 때문에, 대부분 둘을 합쳐서 사용하고 또 Domain Model이라고 합니다.

감사합니다.

안녕하세요. 레알이님

PM과 DM을 명확하게 나누면, 데이터 저장소가 JPA에서 다른 기술로 변경되었을 때, 비즈니스 로직을 거의 바꾸지 않고, 다른 저장소로 변경이 용이하다는 장점이 있습니다.

그런데 막상 PM과 DM을 명확하게 나누게 되면, 둘을 어디선가 매핑해야 하는데, 실용성이 매우 떨어집니다.

그리고 DM은 영속 상태 같은 개념이 없기 때문에, JPA가 제공하는 지연로딩, 더티체킹 등등의 기능도 사용할 수 없습니다.

그래서 저는 실용적인 관점에서 PM을 DM처럼 사용합니다.

이런점 때문에 거의 사용하지는 않지만 데이터 저장소의 변경이 중요한 경우에는 프로젝트 같은 경우에는 DM을 별도로 두기도 합니다.

도움이 되셨길 바래요.

네 화이팅^^!

와 답변 수준의 깊이가 역시 남다르시네요! 감동이에요! 
답변 주셔서 정말 감사드립니다!!

영한님 마지막으로 한 가지 더 궁금한 점이 있는데요. 
PM을 사용하는 경우에는 어쩔 수 없이 getter가 많이 생길 것 같은데요.
캡슐화 측면에서는 별로일 수도 있겠다는 생각이 들었었거든요. 
혹시 실무에서 이런 점을 극복하기 위해 toDTO 메서드를 PM에 두고 getter를 제거하는 방법도 사용하시나요?
(레이어가 분리 관점에서는 좋지 않을 것 같지만요..ㅎ)
아니면 이를 극복하기 위한 다른 방법이 있을까요?