🌈 [Section3] 6. [ Spring MVC ] Spring Data JDBC 2

📕 오늘 배운 내용!

• DDD (Domain Driven Design)
• 애그리거트 (Aggregate)
• 페이지네이션
• n+1 문제

---

✏️ DDD (Domain Driven Design)

• 더 나은 애플리케이션 설계를 위한 도메인 위주의 설계 기법
• 모든 기능을 도메인 모델 위주로 돌아가게 설계하는 기법

✔️ 도메인 (Domain)

• 우리가 실제로 현실 세계에서 접하는 업무의 한 영역 ( 비즈니스적인 어떤 업무 영역 )
• 도메인 지식(Domain Knoledge)들을 서비스 계층에서 비즈니스 로직으로 구현해야함
  ⠀
  Ex. 배달 주문 앱의 상위 수준 도메인 - 회원 / 주문 / 음식 / 결제 / 배달 등
  ⠀
  이 안에서도 도메인을 하위 수준 도메인으로 세분화할 수 있음 ⬇️
  Ex. 주문 - 주문자 정보 / 주문 정보 / 음식 정보 / 주소 정보 등

---

✔️ 도메인 지식 (Domain Knoledge)

• 그 도메인의 전문화된 관련 지식

[참고] https://ko.wikipedia.org/wiki/%EB%8F%84%EB%A9%94%EC%9D%B8_%EC%A3%BC%EB%8F%84_%EC%84%A4%EA%B3%84

✔️ 빈약한 도메인 모델 vs 풍부한 도메인 모델
빈약 - Service 클래스에 기능 집중 되어 있고, Entity 클래스에는 기능이 없고 필드만 있음
풍부 - Service 클래스의 기능이 축소 되고, Entity 클래스에 기능이 많이 들어있음

---

✏️ 애그리거트 (Aggregate)

• 비슷한 범주의 연관된 업무들을 하나로 그룹화 해놓은 묶음
  (비슷한 업무 도메인들의 묶음)
• DDD(Domain-Driven Design)의 패턴

Ex. 배달 주문 앱에서 - 회원 애그리거트 / 주문 애그리거트 / 음식 애그리거트 / 결제 애그리거트 등
( 한 애그리거트 안에는 1개 이상의 도메인(하위 수준 도메인)들이 존재 )

[참고] https://www.alibabacloud.com/blog/an-in-depth-understanding-of-aggregation-in-domain-driven-design_598034

 

✏️ 애그리거트 루트 (Aggregate Root)

• 루트 엔티티(Root Entity)라고도 함
• 하나의 애그리거트를 대표하는 도메인
  ( 한 애그리거트 안의 1개 이상의 도메인들 중에 그 애그리거트를 대표할 수 있는 도메인 )

Ex. 아파트(애그리거트)의 1,2,3동의 동대표들 (애그리거트 루트)

• 애그리거트 내의 도메인들 중, 다른 모든 도메인들과 직간접적으로 연관이 되어 있는 도메인들

Ex.

• 회원 애그리거트
  ➜ 회원 정보가 애그리거트 루트
  ( 회원 정보를 알아야 다른 도메인들(회원 포인트, 회원 등급 등)을 알 수 있음 )
  ⠀
• 주문 애그리거트
  ➜ 주문 정보가 애그리거트 루트
  ( 주문 정볼르 알아야 다른 도메인들(주문자, 주문 음식 등)을 알 수 있음 )
  ⠀
  ❗ 데이터베이스 테이블 관계로 보면,
  한 애그리거트 안에 애그리거트 루트 - 부모 테이블 / 다른 도메인들 - 자식 테이블

• 애그리거트 루트(Aggregate Root)의 기본키 정보를 다른 도메인들이 외래키 형태로 가지고 있음
  ( 그래야 직간접적으로 정보를 빼와 원하는 정보를 알 수 있으니까 )

Ex. 관계형 데이터베이스에서 A 테이블 / B 테이블이 있을 때,
A 테이블의 기본키를 B 테이블이 가지고 있다면,
A = 부모 테이블 / B = 자식 테이블

❗ 여기서 자식 테이블(B)이 가지고 있는 A 테이블의 기본키 = 외래키

---

🌼 애그리거트 간 관계 예시

프로젝트 실습에서 회원 / 주문 / 커피 애그리거트가 있고, 그 각각에 회원 정보(애그리거트 루트), 주문 정보(애그리거트 루트) / 주문 커피 정보, 커피 정보(애그리거트 루트)가 있다.

이를 예시로 생각해보면,

✔️ 데이터베이스 테이블에서 각각의 관계 ( 외래키를 통해 )

( 위에서 표시한 것이 외래키(Foreign Key)가 되는 것 )

❗ 테이블 이름을 대문자로 할 경우, ORDER는 사용 불가
( 쿼리문의 ORDER BY 예약어에 사용되기 때문에 )
➜ ORDERS 사용해야함

• 회원 정보 (Member) - 주문 정보 (Orders)의 관계 👉 1 대 N
  ( 한 명의 회원은 여러 번 주문 가능 )
  
  
• 주문 정보 (Orders) - 커피 정보 (Coffee)의 관계 👉 N 대 N
  ➜ 한명이 여러 종류의 커피 시키기 가능
  ( 하나의 주문이 여러 종류의 커피 포함 가능 )
  ➜ 한 커피를 여러명이 시키기 가능
  ( 하나의 커피가 여러 건의 주문에 포함 가능 )
  
  

❗ 위의 N 대 N 관계는 조인테이블(주문 커피 정보)을 넣어 아래와 같이 변경할 수 있음 ! ⬇️

• 주문 정보 (Orders) - 주문 커피 정보 (Order_Coffee) 👉 1 대 N
  
  
• 주문 커피 정보 (Order_Coffee) - 커피 정보 (Coffee) 👉 N 대 1
  ( 주문 정보(1) - 주문 커피 정보(N) - 커피 정보(1) )

 

✔️ 클래스에서 각각의 관계 ( 객체 참조를 통해 )

• 회원(Member) 엔티티 클래스
  ➜ 1에 해당되는 Member 클래스는 N에 해당되는 Order 클래스의 객체를 참조할 수 있도록 List<Order>를 멤버 변수로 추가

💡 왜 List를 추가할까?
카페에서 커피를 여러번 주문할 수 있듯이, Member 클래스 역시도 여러개의 Order 클래스 객체를 가질 수 있기 때문 !

• 주문(Order) 엔티티 클래스
  ➜ Order 과 Coffee 클래스의 N:N 관계를 각각 1:N 으로 만들주어,
  1에 해당되는 Order 클래스는 N에 해당되는 OrderCoffee 클래스의 객체를 참조할 수 있도록 List<OrderCoffee>를 멤버 변수로 추가
  
  
• 커피(Coffee) 엔티티 클래스
  ➜ Coffee 와 Order 클래스의 N:N 관계를 각각 1:N 으로 만들어주어,
  1에 해당되는 Coffee 클래스는 N에 해당되는 OrderCoffee 클래스의 객체를 참조할 수 있도록 List<OrderCoffee>를 멤버 변수로 추가
  
  
• 주문_커피(OrderCofee) 클래스
  ➜ Order 과 Coffee 클래스의 N:N 관계를 각각 1:N 으로 만들어주는 OrderCoffee 클래스 추가
  ➜ 주문하는 커피가 1잔 이상일 수 있기 때문에 quantity(주문 수량) 멤버 변수 추가
  
  

❗ Spring Data JDBC를 사용하기 위해서는 위에 설계한 도메인 엔티티 클래스의 관계를 DDD(Domain Driven Design)의 애그리거트(Aggregate) 매핑 규칙에 맞게 한번 더 변경해야함

---

✏️ 애그리거트 객체 매핑 규칙

✔️ 1. 모든 엔티티 객체의 상태는 애그리거트 루트를 통해서만 변경 ( 핵심 규칙 )

Ex. 회원 애그리거트 안에 회원 정보(애그리거트 루트)와 회원 포인트가 있다고 할 때,
회원 포인트를 변경하려면 회원 정보라는 애그리거트 루트를 통해 회원 포인트에 접근한 뒤, 그의 상태를 변경해야함

💡 애그리거트 루트를 통해서 나머지 엔티티에 접근한다
➜ 어떤 식으로든 애그리거트 루트가 나머지 모든 엔티티에 대한 객체를 직간접적으로 참조할 수 있다는 의미

💡 ❗ 애그리거트 루트를 통해서만 나머지 엔티티의 상태를 변경해야하는 이유

• 엔티티에 직접 접근해서 정보를 변경할 경우,
  정보를 변경하지 말아야하는 상태에서도 무시하고 변경하게 됨
  ➜ 도메인 규칙에 대한 일관성이 깨짐
  ⠀
• 애그리거트 루트를 먼저 거쳐서 변경될 조건(규칙)을 검증한 후,
  그 검증에 통과하면 엔티티의 정보를 변경할 수 있도록 함
  ➜ 도메인 규칙의 일관성을 유지하도록
  
  Ex. 주문이라는 애그리거트가 있다고 하면 주문 정보(애그리거트 루트), 배달 주소 정보 등이 있을 것임
  배달 중이라고 할 때, 배달 주소 정보를 변경하려고 하면 지금이 조리 중인지 / 배달 중인지 검증한 후,
  조리 중이면 변경 가능하고, 배달 중이면 변경할 수 없도록 이런 규칙의 일관성을 유지하도록 해야함!

 

✔️ 2. 동일한 하나의 애그리거트 내에서는 엔티티 간에 객체로 참조
( 동일한 애그리거트 내의 엔티티끼리 참조할 경우만 적용 )

✔️ 3. 애그리거트 루트 대 애그리거트 루트 간의 엔티티 객체 참조

• 애그리거트 루트 간의 참조는 (객체 참조 대신에) 외래키 방식처럼 ID로 참조
  ( 참조하고자 하는 애그리거트 루트의 ID를 참조값으로 멤버 변수에 추가하는 것 )
• 1대1 / 1대N 관계일 때는 테이블 간의 외래키 방식과 동일
• N대N 관계일 때는 외래키 방식인 ID 참조 / 객체 참조 방식이 함께 사용

 

✔ 사용한 애너테이션 / 인터페이스들

• ✔️ @Id
  ➜ 식별자로 지정

Ex. Member 클래스의 memberId 변수에 이 애너테이션을 붙이면,
Member 클래스의 식별자(Primary Key)로 지정되고,
schema.sql의 데이터베이스 테이블에서 MEMBER 테이블과 매핑됨

 

• ✔️ @Table
  ➜ 클래스명과 별개의 매핑될 테이블명을 정할 수 있음

Ex. Order 클래스에서 @Id 애너테이션을 붙이면 이 클래스는 ORDER 테이블과 매핑됨
But, 이 경우 쿼리문의 ORDER BY 예약어가 있기에 겹치지 않게 @Table("ORDERS")를 붙여주면 ORDER가 아닌 ORDERS라는 테이블명과 매핑됨

 

• ✔️ AggregateReference<T,ID>
  ➜ 1:N 관계일 때,
  Id를 이 클래스로 감싸서 객체 참조가 아닌 ID 참조할 수 있게 감싸줄 수 있음
  ( N:N 관계에서는 사용 X )
  ⠀
  ➜ T - 참조된 집계 루트의 유형
  ➜ ID - 참조된 집계 루트의 ID 유형
  ( 참조된 집계 루트의 ID만 보유 )
  ⠀
  [참고] https://docs.spring.io/spring-data/jdbc/docs/current/api/org/springframework/data/jdbc/core/mapping/AggregateReference.html

 

• ✔️ @MappedCollection(idCloumn = "", keyColumn = "")
  ➜ 엔티티 클래스 간에 연관 관계를 맺어주는 정보
  ( 데이터베이스 의 List, Set또는 속성에 대한 매핑을 구성하기 위한 주석 )
  ➜ idColumn - 자식 테이블에 추가되는 외래키에 해당되는 컬럼명 지정
  ➜ keyColumn - 외래키를 포함하고 있는 테이블의 기본키 컬럼명 지정
  ⠀
  ❗ List의 경우 두 애트리뷰트 모두 적어야하고, Set의 경우 idColumn만 적으면 됨 !

 

• ✔️ CrudRepository<Member, Long>
  ➜ 데이터를 편리하게 데이터베이스의 테이블에 저장, 조회, 수정, 삭제할 수 있는 인터페이스

 

✔ 쿼리 메서드 (Query Method)

• find + By + SQL 쿼리문에서 WHERE 절의 컬럼명 + (WHERE 절 컬럼의 조건이 되는 데이터) 형식

❗ findByxxxx에서 컬럼명은 내부적으로는 테이블의 컬럼명으로 변경되지만,
Spring JDBC 입장에서는 엔티티 클래스를 바라보고 작업을 하기 때문에
반드시 엔티티 클래스의 멤버 변수명을 적어주어야 함

• 쿼리 메서드의 조건에 맞는 데이터를 테이블에서 조회하여 리턴된 결과 데이터를 엔티티 클래스의 객체로 지정
  
  

Ex. Optional< Member > findByEmail(String email); 라는 쿼리메서드를 작성하면,
내부적으로 아래의 SQL 쿼리문으로 변환되어 데이터베이스의 MEMBER 테이블에 질의 보냄
SELECT "MEMBER"."NAME" AS "NAME", "MEMBER"."PHONE" AS "PHONE", "MEMBER"."EMAIL" AS "EMAIL", "MEMBER"."MEMBER_ID" AS "MEMBER_ID" FROM "MEMBER" WHERE "MEMBER"."EMAIL" = ?
➜ 이미 테이블에 등록된 이메일 주소가 있는지 확인하기 위한 용도

 

✔️ @Query

• 개발자가 직접 쿼리문을 작성해서 질의를 할 수 있도록 해줌
  ( 쿼리 메서드명을 기준으로 SQL 쿼리문을 생성하는 것 X )
• 복잡한 쿼리문의 경우 사용

Ex. @Query("SELECT * FROM COFFEE WHERE COFFEE_ID = :coffeeId")

[참고] https://www.javaguides.net/2021/10/spring-boot-pagination-and-sorting-rest-api.html

---

✏️ 페이지네이션

• ✔️ PagingAndSortingRepository < T, ID >
  ➜ Spring 지원 pagination API
  ➜ extends CrudRepository < T, ID > 하는 인터페이스

위 인터페이스를 Repository에 extends 하여 페이지네이션 구현 가능 !

 

✔ 페이지네이션 처리 방식

1. 오프셋 방식

• 스프링에서 지원하는 방식
• 행을 찾을 개수만큼 위에서부터 카운팅하여 찾아가는 방식

Ex. 10만 건의 데이터에서 10만 번째 데이터를 찾으려면 1번부터 쭉 찾아가야함

• 시간이 좀 걸릴 수 있지만 100만건 - 200만건으로 그렇게 느려지지는 않음
• 가장 많이 쓰는 방식
  
  

2. 커서 방식

• 위에서 스크롤 쭉 해서 페이지의 마지막 되면 밑에 페이지가 새로 나타나서 탐색하는 것
• 마지막 조회한 위치를 가지고 있어야 함
• 스크롤 할 때 사용하는 방식

---

✏️ n+1 문제

• 어떤 데이터를 가져오기 위해서 SQL을 한 번 실행했을 때 결과 데이터를 n 건 가져오는데 그 결과 수 만큼 SQL을 추가로 더 실행(N)하는 문제

Ex. N건의 주문에 여러개의 커피 정보

➜ JOIN문을 활용한 네이티브 쿼리를 사용하여 쿼리 실행 횟수를 줄임

➜ SQL IN 연산자 역할을 하는 findAllById(Iterable ids)를 이용해 쿼리 수행 횟수를 줄임

---

😜 실습

• projects 내의 be-template-jdbc 2

💬 궁금했던 점 !
멤버-오더와 오더-오더커피는 똑같이 1:N 관계인데
멤버-오더 관계에서는 오더에서 멤버를 참조하는데
왜 오더-오더커피에서는 오더커피에서 오더를 참조하는게 아니라
오더에서 오더커피를 참조할까??

---

💬 Answer )
JPA같은 경우 둘 다 참조하여 설정할 수 있는데, Spring Data JDBC 에서는 DDD 추구하기 때문에 그 중 원칙인 기본적으로 단방향 관계 추구

[GroupingBy 이용 참고]
https://gem1n1.tistory.com/159

[Java 8 Comparator Comparing Reverse Order 참고]
https://www.javaprogramto.com/2021/12/java-8-comparator-comparing-reverse.html

---

🌈 느낀점

실습 코드 양이 아주 많아서 하루하루 더 바쁜 요즘 ㅠ
뭔가 학습 시간에 코드 치고 이해하기도 빠듯한데
코드에 에러가 나서 그거에 시간을 쏟으면 점점 밀려서 꼬이는 느낌이다 😥
하지만 괜찮아.. 파이팅이다 !!

 

( 본 게시물은 2022/11/02에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90