Conversation
|
|
||
| @Entity | ||
| @SuperBuilder | ||
| @Getter | ||
| @NoArgsConstructor(access = AccessLevel.PROTECTED) | ||
| public class Etc extends Help { |
There was a problem hiding this comment.
(생각거리) Etc는 2가지 일을 하고 있다고 볼 수 있을까요?
- ORM 답게 데이터베이스의 테이블과 자바 객체지향간의 간극을 좁혀주는 일
- Etc에 대한 도메인 로직 관리
There was a problem hiding this comment.
Q. 음.. 2가지 일을 하는게 맞는것 같은데 JPA를 사용하는 모든 객체가 이 부분에서 자유롭지 못할 것같습니다. 다른 방법으로는 어떻게 풀 수 있을 까요?? JPA를 사용하는한 항상 적용되는 문제가 아닐까 라는 생각이 들어서 어떤 부분에서 접근을 해야 할지 헷갈리는 것 같습니다.
관련 이슈: #39
There was a problem hiding this comment.
JPA 엔터티와 도메인 엔터티를 분리하려는 노력은 언제나 맞는 답은 아닐 것 같습니다. 따라서 현재처럼 함께 쓸때와 나눠 쓸때의 각 장단점을 고민해보고 선택해보면 좋을 것 같아요. 우선 나눠질 수도 있다는 점을 말씀드리고 싶었어요.
해당 블로그에서 이를 다루고 있군요
There was a problem hiding this comment.
JPA가 도메인에 위치하는건 사실 레이어드 아키텍처를 위반한 것이라고도 생각이 됩니다.
Q1. 잘 이해 한건지 확인하자면 블로그에서 설명한 대로면 이것을 나누기 위해 POJO랑 JPA Entity로 나누어서 전자는 도메인에 후자는 리포지토리에서 관리를 하게 되는 걸까요?
Q2. 보통은 편의상 JPA엔티티를 도메인에서 사용하게 되는 걸까요? 제가 본 예제들은 보통 이런식으로 개발을 해서요. 이렇게 사용될경우 코드가 JPA라는 기술에 크게 의존하게 되는 듯 합니다.
There was a problem hiding this comment.
Q1. 넵 비즈니스 로직을 담을 도메인 엔터티와, JPA 를 이용하기 위한 https://github.com/entity가 붙은 엔터티 모델을 나눠 관리하게 되는 모양새가 됩니다.
Q2. 그것도 그러합니다. 보통 위 도메인 엔터티와 JPA 엔터티 모델을 하나로 관리하곤 합니다. 그렇게되면 꽤 JPA에 종속되는 프로젝트를 만들게 되겠지요. 이는 장점이 될수도 단점이 될수도 있을겁니다.
변경사항
이번에는 fixme에 못 적었지만 대부분 체크인과 같은 코드이지만 아래 2가지가 다릅니다.