[스진초 5기/개발지식] DDD 설계와 SQL 중심 설계

오늘의 주제는 DDD 설계이다.  DDD 설계는 워낙 요즘 많이 사용하고 팀프로젝트나 실무에선 기본으로 사용되기 때문에 DDD  프로젝트의 구조(패키지 구조 등...)엔 생각보단 익숙하다. 하지만 '왜 사용하지?'라고 물으면 정확히 대답하기가 어렵다. 그렇기 때문에 DDD 설계가 어떤 방식이며 왜 사용되는지 정리할 필요가 있다.

우선 DDD 설계를 설명하기 전 SQL 중심 설계가 무엇인지 알아볼 필요가 있다. 

SQL 중심 설계란?

SQL 중심 설계(SQL-Driven-Design)는 데이터 모델을 중심으로 시스템을 설계하는 것을 의미한다. 데이터베이스의 스키마와 구조가 시스템의 핵심이 되며, SQL(CRUD) 작업이 업무의 주된 임무가 된다. 즉, 데이터의 흐름이 가장 중요한 요소가 되는 설계기법이다. 

설계방법으로는 데이터베이스의 테이블, 엔티티 및 데이터 구조를 먼저 정의하고, 이를 기반으로 비즈니스 로직을 구현하는 방식이다. 데이터 모델링이 선행되고 비즈니스 로직은 이 데이터 모델에 따라 작성된다. 

SQL 중심적인 설계의 문제점은 무엇일까?

잠시 실무 경험을 이야기해 보자면 당시 프로젝트는 회사 내부 솔루션이었고 DDD 기반 설계는 당연히 아니었고, 객체지향과도 거리가 먼 SQL 중심적인 프로젝트였다. 이런 프로젝트를 해보면 알겠지만 DB 스키마 변경이나 추가에 굉장히 취약해진다. 칼럼 하나 변경하면 그 관련 테이블의 CRUD를 다 찾아서 변경하고 문제가 없는지 확인해야 하는 등 작업이 매우 리스크 있게 진행된다. 

이렇듯 SQL 중심적인 설계는 SQL에 의존성을 가지게 된다. 우린 객체지향 프로그래밍을 잘 쓰기 위해서 객체의 책임을 부여하고 역할에 따라 분리하며 계층화시켜야하지만 SQL에 강한 의존을 맺는 이상 로직의 주체는 객체가 아닌 SQL 매핑 작업에 넘어가버린다. 모든 작업을 할 때 쿼리문을 우선 생각해야 하며 객체(테이블)의 연관관계가 많아질수록 쿼리의 복잡도는 증가될 것이다. 이러면 프로젝트의 유지보수나 확장성이 굉장히 떨어지게 된다. 

SQL 중심설계는 확장 가능성이 적은 소규모 프로젝트에서는 큰 효율을 얻을 수도 있지만, 규모가 커지고 지속적인 유지보수와 확장이 필요 프로젝트는 효율이 떨어진다.

DDD 설계의 등장 

위에서 나타난 문제를 해결해 주는 설계기법이 바로 DDD 설계이다. DDD 설계는 우선 비즈니스 요구사항을 올바르게 이해하기 위해 시작되었다. 애플리케이션의 설계과정이나 개발과정 중 해당 도메인에 대한 이해가 부족하면 완성도 있는 프로젝트 구성은 불가능하다. 그렇기 때문에 DDD 설계는 우선적으로 비즈니스 도메인, 즉 실제 비즈니스 프로세스와 도메인 개념을 중심으로 시스템을 설계한다. 핵심은 비즈니스 도메인 개념과 로직이며, 도메인 간의 상호작용이 설계의 중심이 된다.

예를 들어 설명하자면, 배달어플을 만든다고 가정하면 우린 회원, 상품, 결제, 진행 사항... 등의 덩어리들을 추출해 낼 수 있다. 이 덩어리들이 도메인이라 생각하면 된다. 여기서 분리한 도메인들은 하나의 서비스를 구성하기 위해 서로 상호작용하지만 각각의 책임과 역할도 부여되게 된다. 

객체가 책임과 역할을 가지며 서로 상호작용한다의 의미는 높은 응집도와 낮은 결합을 가진 상태가 된다는 의미이며, 이를 통해 SQL 중심 설계의 문제점인 유지보수와 확장에 대해서도 유연성을 갖게 된다. 

그리고 설계한 도메인은 엔티티(Entity)와 매우 밀접한 관계가 된다. 엔티티는 도메인 내에서 개별적으로 식별 가능한 무엇인가를 나타내는 중요한 개념이다. 엔티티는 상태와 동작을 가지며, 그것을 기반하여 도메인의 로직을 수행할 수 있다. 

스프링의 관점에서 본다면 엔티티는 식별가능(ID)하며 DB의 테이블과 1:1 매핑된다는 것을 알 수 있다. 이러한 엔티티는 상태 변경에 대한 비즈니스 로직 가지고 있으며, 그 기반으로 서비스에서 비즈니스 로직을 처리하는데 도움을 주는 역할을 수행하게 된다.

여기서 알 수 있듯이 데이터 모델은 SQL 중심 설계와 다르게 비즈니스 요구사항을 지원하는 도구로써 사용이 된다.

DDD 설계 vs SQL 중심 설계

DDD 설계	SQL 중심 설계
도메인 중심 설계	데이터베이스 중심 설계
도메인의 문제 영역을 중심으로 설계	데이터베이스 구조와 데이터의 흐름을 중심으로 설계
도메인 모델을 통해 도메인 일관성 유지	데이터베이스 정규화를 통해 데이터 일관성 유지
도메인 모델을 통해 비즈니스 로직 처리	데이터베이스 쿼리를 통해 데이터 처리
도메인 모델이 변경되더라도 시스템의 일부분만 변경	데이터베이스 구조가 변경되면 시스템 전체에 영향

Reference

https://diary-blockchain.tistory.com/283

https://youwjune.tistory.com/38

https://www.youtube.com/watch?v=_tMJPysViNU

https://hudi.blog/problems-sql-centered-development/