[Spring]Spring Data JDBC - 도메인 엔티티&테이블 설계

Spring MVC - Controller + Service

[Spring]Spring MVC

[Spring]Spring MVC - Controller 클래스 구조 생성 및 설계

[Spring]Spring MVC - Controller 클래스에 핸들러 메서드(Handler Method) 구현

[Spring]Spring MVC - Controller 클래스에 ResponseEntity 적용

[Spring]Spring MVC - Controller 클래스에 DTO 적용

[Spring]Spring MVC - DTO 유효성 검증(Validation)

[Spring]Spring MVC - DI를 통한 API 계층 ↔ 서비스 계층 연동

[Spring]Spring MVC - 매퍼(Mapper)를 이용한 DTO 클래스 ↔ 엔티티(Entity) 클래스 매핑

[Spring]Spring MVC - @ExceptionHandler를 이용한 예외처리

[Spring]Spring MVC - @RestControllerAdvice를 이용한 예외처리

[Spring]Spring MVC - 비즈니스로직 예외 던지기(throw) 및 처리

[Spring]Spring MVC - Custom Exception을 이용한 클라이언트 출력

 

Spring Data JDBC

[Spring]JDBC(Java DataBase Connectivity)

[Spring]SQL Mapper vs. ORM

[Spring]Spring Data JDBC, Spring Data JDBC 사용법

[Spring]Spring Data JDBC - 도메인 엔티티&테이블 설계

[Spring]Spring Data JDBC - 도메인 엔티티 클래스 정의

[Spring]Spring Data JDBC - Service, Repository 구현

 

Spring Data JPA

[Spring]JPA(Java Persistence API)

[Spring]JPA - Entity ↔ DB Table Mapping

[Spring]JPA - Entity ↔ Entity Mapping

[Spring]Spring Data JPA - 데이터 액세스 계층 구현

[Spring]ORM, Hibernate, JPA, Spring Data JPA

[Spring]트랜잭션(Transaction)

[Spring]트랜잭션(Transaction) - @Transactional

 

지난 글에선 JDBC, ORM, Spring Data JDBC에 대해 살펴보았다.

 

이번 글부터는 Spring Data JDBC를 기반으로 데이터 액세스 계층을 연동하는 법에 대해서 알아본다.

 

들어가기 전에 먼저 새로 나오는 단어들을 살피고 가자.

 

도메인(Domain)

도메인이란 한 마디로 현실 세계에서 접하는 업무의 한 영역이라고 할 수 있다.

 

혹은 개발자가 소프트웨어로 “해결하고자 하는 문제 영역”을 의미한다고 할 수도 있다.

 

조금 더 구체적으로 도메인은 '영역, 범위'의 뜻을 가지고 있으며 프로그래밍의 경우엔

 

애플리케이션 내의 로직들이 관여하는 정보와 활동의 영역이라고 생각하면 편하다.

 

예를 들어 배달 주문 서비스를 만들 때 회원을 등록하거나 삭제하는 작업은 "회원"과 관련된 작업들이고,

 

따라서 "회원"이라는 도메인이 있다고 볼 수 있게 된다.

 

위 그림은 배달 주문 도메인의 하위 도메인을 나타내고 있다.

 

DDD(Domain Driven Design)

도메인 주도 설계(Domain Driven Design, DDD)란 말 그대로 도메인을 중심으로 한 소프트웨어를 설계 기법을 말한다.

 

더 구체적으로는 도메인 모델이라고 하는 소프트웨어 추상화를 달성하기 위한 원칙과 패턴의 집합이라고 할 수도 있다.

 

또한 DDD의 핵심 목표는 Loose Coupling, High Cohesion으로, 모듈 간의 의존성은 최소화하고 응집성은 최대화해

 

핵심적인 기능은 모두 가지면서도 가벼운 설계를 만드는 것이다.

 

DDD에 관한 더 자세한 설명은 아래 글에 쓰여있다.

 

2022.09.10 - [개발/Spring] - [Spring]도메인 주도 설계(Domain Driven Design, DDD)

[Spring]도메인 주도 설계(Domain Driven Design, DDD)

 

애그리거트(Aggregate)

Aggregate는 한 마디로 말하자면 고유의 비즈니스 목적 수행을 위한 데이터 객체들의 집합이다.

 

또한 한 단위로 취급 가능한 경계 내부의 도메인 객체로서, 한 개의 루트 엔티티와 기타 엔티티+Value Object로 구성된다.

 

여기서 VO(Value Object)란 DTO와 유사하지만 Setter()메서드가 없는(즉, 생성 후 수정이 불가능한),

 

값(Value)을 저장하기 위한 객체를 말한다.

 

더 직관적으로 파악하기 위해 위에 올렸던 도메인 그림을 조금 더 세분화해보자.

 

회원, 주문, 음식, 결제라는 상위 도메인 아래에 각 정보를 담은 하위 도메인이 위치한 것을 확인할 수 있다.

 

여기서 Aggregate는 회원, 주문, 음식, 결제와 같은 비슷한 업무 도메인의 묶음을 말한다.

 

따라서 위 그림의 Aggregate는 총 네 개가 된다.

 

또한 Aggregate는 한 개의 루트 Aggregate(엔티티)를 가진다고 했는데,

 

루트 Aggregate란 데이터베이스 테이블의 Primary Key에 해당하는, Aggregate를 식별할 수 있는 값을 말한다.

 

위 그림에 적용하면 다음과 같이 될 것이다.

 

Aggregate Root에 해당하는 값을 다른 Aggregate의 도메인이 외래 키의 형태로 참조하는 것을 확인할 수 있다.

 

참고로 RDB에서 A 테이블의 기본키를 B 테이블이 가지고 있다면 A는 부모 테이블이 되고  B는 자식 테이블이 되며,

 

B인 자식 테이블이 가지고 있는 A 부모 테이블의 기본키를 외래 키라고 한다.

 

또한 굳이 도메인을 묶어 Aggregate를 만들고 Aggregate Root까지 찾는 이유는 

 

Spring Data JDBC가 ORM을 기반으로 하기 때문이다.

 

지난 글에서도 알아봤듯이 ORM은 객체와 테이블을 매핑하는 기술이기 때문에, Aggregate와 Aggregate Root를 정의해

 

데이터 테이블과의 매핑을 손쉽게 이룩하도록 도와야 한다.

 

계속해서 지난 글까지 구현해왔던 앱에 Spring Data JDBC를 적용하기 위해 도메인 엔티티를 구성해 보자.

 

애플리케이션 도메인 엔티티 및 테이블 설계

먼저 구현해오던 앱의 도메인 엔티티 모델을 만든다.

 

계속 구현해오던 앱은 결제 및 배송이 필요 없으므로 굉장히 간단하게 설계된 것을 확인할 수 있다.

 

또한 이전과는 다르게 한 명의 회원이 하나 이상의 커피를 주문할 수 있도록 변경되었으며

 

결과적으로 세 개의 Aggregate와 그 루트가 정해진 것도 볼 수 있다.

 

각 Aggregate 사이의 구체적인 관계는 아래와 같다.

 

• 회원 정보(Member)와 주문 정보(Order)의 관계(1 대 N)
  
  
  • 한 명의 회원이 여러 번 주문 가능
• 주문 정보(Order)와 커피 정보(Coffee)의 관계(N 대 N)
  
  
  • 하나의 주문은 여러 종류의 커피를 가질 수 있음
  • 하나의 커피는 여러 건의 주문에 속할 수 있음
• N 대 N의 관계는 일반적으로 1 대 N, N 대 1의 관계로 재설계
  
  
  • 주문 정보(Orders)와 주문 커피 정보(Order_Coffee) - 1 대 N
  • 주문 커피 정보(Order_Coffee)와 커피 정보(Coffee) - N 대 1

 

엔티티 클래스 간의 관계

계속해서 Aggregate를 기준으로 도메인 엔티티 클래스 간의 관계를 나타내 보자.

 

잠시 후에 데이터베이스 테이블을 설계하면서도 보게 되겠지만

 

데이터베이스 테이블 간의 관계는 외래 키를 통해 맺어지고 클래스 간의 관계는 객체의 참조를 통해 맺어진다.

 

JPA를 공부하며 언급하겠지만 Spring Data JDBC는 단방향 연관 관계만 지원하기 때문에

 

위 그림의 OrderCoffee 클래스 안에는 Order와 Coffee를 참조할 변수가 없다.

 

각 엔티티 클래스를 간략하게 살펴보자.

 

• 회원(Member) 엔티티 클래스
  
  
  • Member와 Order의 관계는 1 대 N의 관계(한 명이 여러 건 주문 가능) → Member 클래스에 List<Order> 추가

• 주문(Order) 엔티티 클래스
  
  
  • Order와 Coffee는 N 대 N의 관계 → N 대 N의 관계를 1 대 N의 관계로 만들어주는 List<OrderCoffee>를 추가
• 커피(Coffee) 엔티티 클래스
  
  
  • Coffee와 Order는 N 대 N의 관계 → N 대 N의 관계를 1 대 N의 관계로 만들어주는 List<OrderCoffee>를 추가
• 주문_커피(OrderCoffee) 클래스
  
  
  • Order와 Coffee가 N 대 N 관계 → 두 클래스의 관계를 각각 1 대 N의 관계로 만들어주기 위한 OrderCoffee 클래스 추가
  • 주문하는 커피가 한 잔 이상일 수있기 때문에 quantity(주문 수량) 추가
    

마지막으로 설정된 도메인 엔티티의 관계를 기반으로 데이터베이스 테이블을 설계하자.

 

데이터베이스 테이블 설계

각 테이블의 컬럼이 엔티티 클래스의 멤버 변수와 매핑되도록 테이블을 생성한다.

 

위 그림이 바로 도메인 엔티티 클래스 간의 관계를 토대로 만든 데이터베이스의 테이블 설계이다.

 

엔티티 클래스 간의 관계는 객체의 참조로 이루어지지만 테이블 간의 관계는 외래 키(Foreign key) 참조로 이루어진다.

 

참고로 주문 테이블의 이름이 ORDER가 아니라 ORDERS인 이유는

 

‘ORDER’가 SQL 쿼리문에서 테이블의 로우를 정렬하기 위해 사용하는 ‘ORDER BY’라는 예약어에 사용되기 때문이다.

 

이렇게 해서 Spring Data JDBC를 적용하기 위한 설계가 끝났다.

 

다음 글에서는 실제로 코드에 위 설계를 적용해 본다.