• 프로젝트 환경설정

  • 요구사항 분석

  • 도메인과 테이블 설계

  • 아키텍처 구성

  • 핵심 비즈니스 로직 개발

  • 테스트

  • 웹 계층 개발

도메인기반설계? 테스트용도로 h2Database를 써보띾?

H2 Database

  • 개발이나 테스트용도로…​

  • ;MVCC=TRUE 옵션 사용?

  • 저장시 왜 id를 반환하기

    • command랑 query를 분리하라. 저장하고나면 command성이여서 id정도만 리턴하도록 설계함

Tip

Editor > Live Template 에 custom에 tdd 만 입력하면 given/when/then 만들어주도록 추가함

  • @Transactional 이 테스트에 있으면 다 롤백함

    • @Rollback(false) 추가하면 안지워짐

  • equals 할 떄 어떻게 같아지는지는?

    • 영속성 트랜잭션안에서는 저장하고 조회하면 똑같게 나옴, id 값이 같으면 같은 entity로. 그래서 select 쿼리도 안날라가고 영속성 컨텍스트에 있는 캐시가 반환.

  • query 파라미터가 안나가는데…​

    • logging.level.org.hibernate.type: trace 이렇게 주면 출력됨

    • com.github.gavlyukovskiy.spring-boot-data-source-decorator 라이브러리 활용

      • p6spy-spring-boot-starter

도메인 분석 설계

목차

  • 요구사항 분석

  • 도메인 모델과 테이블 설계

  • 엔티티 클래스 개발

  • 엔티티 설계시 주의점

  • 기능 목록, 유저스토리, …​

  • 모델링 중요

  • jpa 다:다 관계는 쓰면 안됨

  • 양방향보더는 단방향

  • "회원이 주문을 하니까"를 생각해서 회원이 주문을 가진 것이 아니라 ('회원을 통해서 항상 주문이 일어난다’가 아니라) 시스템관점에서 맴버랑 오더랑 동급으로 보고 고민.(주문을 생성할때 회원이 필요하다)

    • 실제 쿼리에서도 오더에서 필터링 조건으로 맴버가 들어가는 것이지, 맴버를 조회한 뒤 주문을 조회하는게 아니다.

  • 싱글 테이블 전략, 단일 테이블 전략

  • 엔티티분석과 테이블분석을 구분한듯

  • 양방향 관계에서…​

    • 일대다 관계에서는 무조건 다에 외래키가 존재

    • 외래키가 가까운것에 있는걸 연관관계의 주인으로 정하라(원칙?)

      Note
      외래 키가 있는 곳을 연관관계의 주인으로 정해라.

      연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스상 우위에 있다고 주인으로 정하면 안된다.

  • 실무에서는 @ManyToMany 를 쓰면 안된다.

    • 중간 테이블에 컬럼을 추가할 수 가 없고 세밀하게 쿼리를 실행하기 어렵기 때문. 한계가 있다.

    • 아예 일다대, 다대일 매핑으로 풀어서 사용하자.

  • 내장 타입에는 @Embedded or @Embeddedable

  • 연관관계의 주인을 정해줘야 할 때 @OneToMany(mappedBy = "컬럼명")

    • 어디의 값이 바뀔 때 뭘 믿고 해야하지?

    • foreign key가 가까운곳이 주인으로 잡는게 좋다.

  • @Enumerated(EnumType.ORDINAL) 이 default, EnumType.STRING 추천

  • 외래키를 꼭 걸어야 하나?

    • 시스템마다 다를듯

    • 실시간 트래픽 중요하고 정합성보다는 잘 서비스되는게, 유연하게 - 외래키 빼고 인덱스

    • 데이터가 중요하고 정합성 - 외래키

  • setter를 열면 사이드이펙트가 발생할 수 있으니, setter를 닫고 비지니스 메서드를 제공함

  • 테이블은 타입이 없으므로 컬럼명을 id 로만 하는 것은 구분이 어렵다 그래서 테이블은 관례상 테이블명+id 를 많이 사용한다.

    • memberId or member_id 중요한것은 일관성

  • 값 타입은 이뮤터블하게 하자

    • JPA 스펙상 빈 생성자를 protected 까지 허용

  • 엔티티 설계시 주의점

    • setter 가급적 노. 유지보수가 어렵다. 충분히 setter 없이 개발 가능

    • 모든 연관관계는 지연로딩으로 설정

      • EAGER 즉시로딩은 예측이 어렵고, (맴버 조회할떄 연관된 애들을 모두 조회)

      • LAZY 로 설정하자

      • 특히 JPQL 실행할 떄 N + 1 문제가 자주 발생한다.

      • fetch join 또는 엔티티 그래프 기능 사용

      • @XToOne

('도메인 분석 설계 - 엔티티 설계시 주의점' 부터 보기 - 05:57 ~ )