4장 리포지터리와 모델 구현

[tidavid1]

4장 리포지터리와 모델 구현을 읽고 코멘트를 남겨주세요

[YongNyeo]

엔티티 식별자(ID)를 선정하는데 본인만의 기준이 있는지?

김용상

보안과 기본키 인덱스를 고려했을때 보여지는 기본키에는 UUID를 써왔고 내부적으로 사용하는 것에는 Long타입을 써왔다. 하지만 티스토리나 몇몇 도메인은 그대로 Long타입을 쓰는 것을 보고 어떤 기준으로 식별자를 정해야할지 더 고민이 됩니다. 웬만해서는 DB의 AutoIncrement 를 사용할 것 같지만, 특정 경우에 대해서는 다른 기본키를 사용해볼 고민이 필요할 것 같습니다.

소승수

어지간하면 자동증가를 사용하는 것 같다. 예를 들어 주민등록번호처럼 변하지 않을 것 같은 숫자도 정책 등에 의해 변경될 때가 있다. PK는 불변해야하기 때문에, 자동증가를 사용하거나 UUID를 사용하는 것이 좋아보인다. 또한 해당 ID가 공개가 되어도 괜찮은지 고민해봐야한다.

홍지인

(습관처럼) Long 타입을 사용해서 데이터베이스의 자동 증가 컬럼을 사용해서 식별자를 생성해왔다.

이경민

ID가 인덱스로도 활용이 되기에 성능관련된 부분까지도 신경써야 한다고 생각. 결국 DB 자동 증가가 맞는거 아닐까..?

임수진

아직 나만의 기준이 생길만큼 프로젝트를 많이 하지 않아서 대부분이 사용하는 Long 타입에 자동증가 칼럼을 사용합니다.

김주환

생성형 고유 값을 쓸때

• 비즈니스적으로 고유값을 쓸때
• 코드 상에서 부득이하게 값을 먼저 넣어줄때

오토, 시퀀셜 값 쓸때

• 디비 인서트로 안정성을 가져가야할때 tip. Long은 엄청 거대하다 한계가 도달할 일은 없을듯요

[tidavid1]

DIP에 대한 엄격한 구현(p. 170)에 대해 어떻게 생각하는지 궁금합니다.

경민

Entity나 Repository를 구현하는 과정에서 JPA에 종속적으로 구현이 된다. ← 저는 이방식이 맞다고 봄 책에서는 이러한 점과 상반되게 엄격하게 DIP를 나눠 구현하는 방식도 보여주며 이러한 방식으로 구현하는 개발자도 있다고 하는데, 다른 사람의 생각이 궁금해요!

승수

구현 기술이 변경되는 경우가 별로 없다면 이를 너무 엄격하게 구현하면 오히려 너무 복잡성을 증가시키지 않을까?

주환

레포 딴에서는 엄격하게 구현하는게 좋을 것 같아요. 이유는

• 변경 가능성을 누가 어떻게 판단할 수 있나요? 생각보다 예상외의 이유로 변경은 많이 일어납니다.
• 특히 레포는 기능이 하나만 추가 되어도 쿼리가 복잡해 질 수 있습니다. 그렇다면 data jpa 에서 @Query 로 선언한 쿼리들도 Jdbc 템플릿이나 쿼리dsl 로 빼야겠죠?
• 기본 crud 는 data jpa 쓰니까 논외로 두겟습니다

수진

dip를 엄격하게 구현하려고 하다가 구현하는 과정이 더 복잡해질 것 같습니다. 이보다는 jpa 어노테이션을 적절히 사용하는 것이 좋을 것 같습니다.

지인

특정 기술에 의존하지 않는 순수한 도메인 모델을 구축하는 것은 복잡성을 증가시킬 수는 있지만 투머치라고 생각하지는 않는다. 변경을 미리 대비한 코드가 후에 문제를 발생시킬 일이 없다고 생각하기 때문. 단순히 복잡성을 증가시킨다는 이유만으로 구현 기술에 의존하는 도메인 모델을 구축한다는 것은 좋은 태도가 아니라고 생각한다.

용상

DIP를 레포지토리에 적용하게 되면 다소 과한 구현이 된다고 생각해왔습니다. 책 저자 또한 레포지토리를 변경 해본 적이 없다고 했었는데, 다만 주환님의 말씀하신 테스트와 성능향상의 용이성이 있다는 것을 듣고 그 점에 대해서 고민해봐야할 것 같습니다.

[voidmelody]

애그리거트에서 루트 앤티티를 뺀 나머지 구성요소는 대부분 밸류이다. 루트 엔티티 외에 또 다른 엔티티가 있다면 진짜 엔티티인지 의심해 봐야 한다. 단지 별도 테이블에 데이터를 저장한다고 해서 엔티티인 것이 아니다. 애그리거트에 속한 객체가 밸류인지 엔티티인지 구분하는 방법은 고유 식별자를 갖는지를 확인하는 것이다. 하지만 식별자를 찾을 때 매핑되는 테이블의 식별자를 애그리거트 구성요소의 식별자와 동일한 것으로 착각하면 안된다.

별도 테이블에 데이터를 저장한다는 것이 엔티티를 의미한다는 것이 아님을 생각하며 작성하자.

즉시 로딩 방식으로 설정하면 애그리거트 루트를 로딩하는 시점에 애그리거트에 속한 모든 객체를 함께 로딩할 수 있는 장점이 있지만 이것이 항상 좋은 것은 아니다. 컬렉션에 로딩 전략을 즉시 로딩(EAGER)로 설정할 시 테이블 조인이 발생하고 해당 조인은 카사디안 조인을 사용하기에 쿼리 결과에 중복을 발생시킨다. 물론 하이버네이트가 중복된 데이터를 알맞게 제거해주지만, 데이터가 많을 수록 실제 필요한 행 갯수에 비해 발생하는 쿼리가 많아진다.

상태 변경을 위해 즉시 로딩을 통해 과연 애그리터를 완전히 로딩할 필요가 있을까? 상태를 변경하는 시점에 필요한 구성 요소만 로딩하는 지연 로딩을 통해서도 해결할 수 있다.

[suzzingV]

JPA를 공부하고 있는 시점에 이 챕터를 읽게 되어 복습이 되었다. 팀원들과 id 생성에 관한 이야기를 해보며 아무 생각 없이 Long 타입에 자동증가 컬럼으로 id를 생성하는 것에 다시 생각해보게 되었다.

[happyjamy]

Id 코드 상에서 만들어서 사용하면 보통 따로 class 를 빼서 만들었는데, 레포에서 만드는 것이 옳은 구조라는 생각을 했다.

[JIN-076]

리포지토리를 구현하는 전반적인 방법에 대해서 복습을 할 수 있어서 개념을 다시 한번 정리할 수 있었다. 또한 엔티티의 식별자를 만드는 과정에서 어떠한 명확한 이유나 근거 없이 습관적으로 데이터베이스의 증가 컬럼을 활용했었는데, Id 생성에 대한 여러 방식을 이해하고, 스스로가 채택한 방식에 대해서 명확한 근거를 갖는 것이 좋을 것 같다! 고민해볼 만한 좋은 내용인 것 같다!