도메인 개발

어노테이션 동작 원리

• @SpringBootApplication이 붙은 클래스가 속한 패키지에 있는 모든 컴포넌트(@Repository, @Service, ...)가 스프링 빈에 자동 등록된다.
• @PersistenceContext : 스프링이 엔티티매니저 자동 주입
• @PersistenceUnit : 스프링이 엔티티매니저팩토리 자동 주입
• @Transactional(springframework) : JPA의 모든 데이터 작업은 트랜잭션 안에서 진행해야 한다.
  - readOnly : 사용시 조회 작업 최적화. 조회 작업이 많다면 클래스에 선언, 아니라면 각각 선언. 기본값은 false
• @Autowired
  - 값이 바뀌면 안되기 때문에 final 설정
  - 필드 주입 : 테스트를 하거나 할 때 필드를 바꿀 수 없다.
  • setter 메서드 주입 : 테스트 코드 작성시 변수에 넣고 싶은 걸 넣을 수 있다. 하지만, 쉽게 변경될 수 있으므로 실행 중에 위험할 수 있다.
  • 생성자 주입 : 추천함, 요새는 어노테이션 없어도 알아서 주입해 줌.
• @AlArgsConstructor : 모든 필드의 생성자 생성
• @RequiredArgsConstructor : final 필드만 생성자 생성, @Autowired/@PersistenceContext 등 대체 가능

Test

인메모리 DB

• src/test/resources 폴더 생성
• application.yml 복사
• spring.datasource.url: jdbc:h2:mem:test
  
  

회원

• 회원 등록 : 동시에 DB 접근하면 중복 검증을 못하는 경우가 있음. 이럴 때는 username 필드에 유니크 제약 조건을 설정하자.
• 회원 한 명 조회
• 모든 회원 조회
• 회원명으로 조회
  
  

주문

• 생성 메서드 : 주문 생성에는 orderItem, delivery 등 setter로 모두 생성해야 하므로 복잡하다. 이런 경우에는 생성 메서드를 만들어 놓으면 좋다.

  정적 팩토리 메서드(static factory method)

  객체 생성의 역할을 하는 클래스 메서드이다.
  생성자를 통해 직접적으로 객체를 생성하는 것이 아닌 메서드를 통해서 객체를 생성하는 것을 의미한다.
  장점
  - 생성자는 내부 구조를 알고 있어야 목적에 맞게 객체를 생성할 수 있지만, 정적 팩토리 메서드는 메서드 이름에 객체의 생성 목적을 담아낼 수 있다.
  - 호출할 때마다 새로운 객체를 생성할 필요가 없다.
  - 하위 타입의 객체를 반환할 수 있다. (상속 관계)
  - 객체 생성을 캡슐화하여 내부 상태를 외부에 드러낼 필요 없이 객체 생성 인터페이스를 단순화 시킬 수 있다.

  생성 메서드와 기본 생성자를 같이 사용하면 유지보수에 어려움이 있을 수 있으므로, 기본 생성자는 protected로 막아놓는다. 롬복의 NoArgsConstructor 사용

  가변인자(variable argument)

  • 어떤 메서드에서 매개변수를 동적으로 받을 수 있는 방법
  • '타입... 변수명' 으로 사용한다.
  • 가변인자는 내부적으로 배열을 생성해서 사용하기 때문에, 무지성으로 사용하면 안 된다.
  • 가변인자는 가장 마지막에 선언해야 한다.
  • 가변인자를 사용한 메서드는 오버로딩을 하지 않는 것이 좋다.
  • ex) printf

• 주문 취소 : 이미 배송된 상품은 취소 불가능

  getter vs 필드 직접 접근

  아무거나 사용해도 상관 없다. 다만, 드물게 조회한 엔티티가 프록시 객체인 경우 필드에 직접 접근하면 원본 객체가 아닌 프록시 객체의 필드에 접근하여 equals, hashcode 구현에 문제가 될 수 있다.
  따라서 엔티티에 equals, hashcode를 구현할 때는 getter를 사용하고, 그게 아니라면 둘 다 상관없다.

• 주문 검색 : 회원이름, 주문상태

  동적쿼리 작성

  1. if문과 문자열 연산을 이용한 하드한 동적쿼리 작성 -> 에러 많고 불편함
  2. JPA Criteria -> 코드 해석, 유지보수가 어렵다
  3. Querydsl -> 자주 사용

• 주문 생성

  cascade의 범위?

  명확하게 구분하기는 어렵지만, Order가 Delivery와 OrderItem을 관리한다면 cascade를 사용한다. 만약 Delivery나 OrderItem이 다른 곳에서도 많이 사용된다면 마구 사용하면 안 된다.

참고

도메인 모델 패턴

서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할만 하고, 엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 패턴

트랜잭션 스크립트 패턴

엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 패턴

현재 내 문맥에서 유지보수가 쉬운 패턴을 골라서 사용해야 한다.

한 서비스 안에 여러 패턴이 존재할 수 있다.