DDD 핵심만 보고가자

📜서론

매번 DDD라는 단어를 어렴풋이 들었었지만, 공부해 본 적은 없었습니다. 이번 내배캠 부트캠프에서 좋은 기회로 멘토님께서 DDD 특강을 진행해 주셨고, 덕분에 많은 것을 배우고 느낄 수 있었습니다.

이번 글에서는 해당 특강에서 배운 내용을 정리하고자 합니다. 서동우 멘토님, 감사합니다. 🥲

 

📍 Domain이란?

먼저 비즈니스 도메인이란 유사한 업무의 집합을 의미합니다.(DDD에서의 Domain은 비즈니스 도메인을 의미합니다)

 

📍 DDD란?

DDD(Domain-Driven Design), 도메인 주도 설계란 도메인 패턴을 중심에 놓고 설계하는 방식을 말합니다.

 

일반적으로 개발을 진행한다면 ERD를 작성하고, Entity를 개발합니다.

유저는 여러개의 주문을 할수있으니깐 1:N, 주문 하나당 리뷰 한개를 작성할 수 있으니깐 1:1, …..

 

이렇게 작성한뒤 Entity에 정직하게 모든 연관관계를 FK로 맺었습니다. 

하지만 이렇게 진행하면 다음과 같은 문제가 발생했었습니다.

 

⚠️ FK를 맺을 때 발생하는 문제점

1️⃣ 규모가 커질수록 유지보수가 어려움

작은 서비스에서는 FK로 모든 관계를 관리하는 것이 큰 문제가 되지 않습니다. 하지만 서비스 규모가 커지고 도메인이 많아질수록 테이블 간의 관계가 복잡해지면서 특정 테이블을 변경할 때 연관된 다른 테이블들도 수정해야 해서 유지보수가 어려워집니다.

 

2️⃣ 성능 저하 (N+1 문제 발생)

FK가 많아지면 데이터를 조회할 때 JOIN을 자주 사용하게 됩니다. 특히, OneToMany(1:N) 관계에서 발생하는 N+1 문제는 심각한 성능 저하를 초래합니다. 예를 들어, 유저 정보를 조회하면서 주문 정보를 가져오려고 할 때, 한 번의 조회가 N개의 추가 쿼리를 발생시키는 문제가 생길 수 있습니다.

 

3️⃣ 도메인 로직보다 연관관계 유지에 더 많은 시간 소비

원래는 비즈니스 로직과 도메인 기능을 개발하는 데 집중해야하지만, FK로 모든 관계를 연결하면 무결성 제약 조건, 순환 참조 문제 등으로 인해 예상치 못한 오류가 계속 발생할 가능성이 높습니다. 뭐 하나 수정하면 백만개 수정해야할 수도..

 

이러한 문제를 해결하기 위한 이유로 DDD가 떠오르게 된것 같습니다. 

제가 이번에 프로젝트로 진행한 온라인 음식 주문 서비스를 예로 DDD에 대해 간략히 설명하겠습니다.

몇가지 주요 도메인은 다음과 같습니다.

- 주문

- 주문 아이템

- 상품

- 유저

- 가게

- 가게 주소

 

해당 도메인에서 종속 적인 관계를 찾아봅시다. 이때 종속적인 관계란 영속성 전이가 가능한 존재. 다른 의미로는 같은 Lifecycle을 가지는 존재하고 보시면 됩니다. 여기서는 일부만을 작성하겠습니다.

- 주문, 주문 아이템

- 상품 

- 가게, 가게 주소

- 유저

유저가 삭제된다고 주문에 영향을 미치면 안됩니다. 상품이 생긴 뒤에 주문 아이템이 생길 수 있습니다. 어떻게 나뉘는지 헷갈린다면 해당 예시를 생각해보시면서 영속성 전이(Cascade)가 가능한 도메인, 생명주기가 같은 도메인을 생각해보시면 될것 같습니다.

 

먼저 이렇게 구조를 짜고 Entity를 설계한다면 독립적으로 확장 가능한 구조를 짤 수 있습니다.

 

 

 

- 회원

- 주문

- 매장

- 결제

 

여기에 몇가지 세분화 하여 하위 도메인들을 포현하겠습니다.