[Spring] DDD 설계 와 SQL 설계

DDD(Domain Driven Design) : 도메인 주도 설계

소프트웨어가 다루는 도메인과 비즈니스 로직을 중심으로 설계하는 방식

-> 소프트웨어 시스템에서 사용되는 모든 개념과 동작을 도메인 모델로 표현

: 도메인 우선 순위 -> 도메인 쪼갬 -> (도메인 기반 ERD) -> 도메인 단위로 클래스 다이어그램 -> 전체적으로 고도화

 

*도메인이란? 

사용자가 받는 서비스의 큰 단위

 

장점

- 비즈니스 로직에 중점을 둬서 개발할 수 있다. -> 요구사항 변경에 대흥 용이

- 도메인 모델이 비즈니스 요구사항을 명확하게 표현하고, 이해하기가 쉽기 때문에 의사소통이 원활해짐

- 비즈니스 로직이 중심이 되기때문에 코드의 유지보수와 확장성이 높아짐

 

단점

- 복잡한 비즈니스 도메인 모델을 구현하는 것이 어렵다.

 

사용목적

비즈니스 도메인에 중점을 두어야 하는 경우

 

ex. 

온라인 쇼핑몰 시스템을 비즈니스 도메인 모델

Customer(고객) : id, name, address, email
Product(제품) : id, name, price, description
Order(주문) : id, customer_id, order_date
LineItem(주문 상품) : id, order_id, product_id, quantity, price

 

 

SQL 설계

SQL중심 설계에서는 데이터베이스를 중심으로 설계하고, 데이터베이스 스키마를 먼저 정의하여 이를 기반으로 SQL쿼리를 작성한다.

: DB우선순위 -> ERD -> 클래스 다이어그램

장점

- 대용량 처리와 관리에 매우 효율적

- 대부분의 프로그래밍 언어와 프레임워크에서 데이터베이스와의 상호작용을 지원하기 때문에 개발속도가 빠름

 

단점

- 데이터베이스 스키마가 변경되면 이에 맞게 코드도 변경되어야 하므로, 유지보수성이 떨어지고 코드의 의존성이 높아질 수 있다.

 

사용목적

데이터 처리와 성능에 중점을 두어야 하는 경우

(대부분의 프로그래밍 언어와 프레임워크에서 DB와의 상호작용을 지원하므로 DB와 쿼리 중심으로 설계하는것이 효과적)

 

ex.

데이터베이스 스키마

학생(Student) : id, 이름(name), 학년(grade)
강의(Course) : id, 이름(name), 학점(credit)
수강(Enrollment) : id, 학생 ID(student_id), 강의 ID(course_id), 수강 학기(semester)

SQL 쿼리계

SELECT Course.name, Enrollment.semester
FROM Course
INNER JOIN Enrollment ON Course.id = Enrollment.course_id
INNER JOIN Student ON Enrollment.student_id = Student.id
WHERE Student.name = '홍길동';

 

DDD 설계 와 SQL 설계 차이

SQL 중심 설계 예시

: SQL 중심 설계에서는 SQL 쿼리를 직접 작성하여 데이터베이스를 조작

-- 학생(Student) 테이블 조회
SELECT *
FROM Student
WHERE id = 1;

-- 학생(Student) 테이블에 새로운 학생 추가
INSERT INTO Student(id, name, grade)
VALUES(2, '홍길동', 2);

 

DDD예시

: 도메인 모델링을 통해 객체를 생성하고, 리포지토리를 통해 데이터베이스에 저장

// 학생(Student) 엔티티 조회
Student student = studentRepository.findById(1);

// 학생(Student) 엔티티 추가
Student newStudent = new Student(2, "홍길동", 2);
studentRepository.save(newStudent);