DDD vs SQL 중심 설계

💻 SQL 중심 설계란?

SQL 중심설계는 시스템을 설계할 때, 데이터베이스를 중심으로 시스템을 설계하는 방법입니다. 따라서 데이터베이스 스키마를 먼저 설계하고, 스키마를 기반으로 서비스의 비즈니스 로직을 작성하게 됩니다.

SQL 중심설계의 가장 큰 단점은 스키마와 비즈니스로직의 강한 결합입니다. 이런 단점에서 파생되는 문제는 다음과 같습니다.

1. 낮은 유연성
   스키마에 대한 비즈니스 로직의 의존성의 높아, DB 구조 변경으로 인해 쿼리를 변경해야 할 상황이 생기게 되면 해당 쿼리를 사용하고 있는 로직들을 찾아 모두 바꿔줘야하는 문제가 생깁니다.
2. 테스트 코드 작성의 어려움
   DB에 대한 의존성이 높기 때문에 테스트코드를 작성할 경우 DB도 같이 설정해 줘야 하는 문제가 발생합니다.
3. 비즈니스 로직의 복잡도 처리 어려움
   비즈니스 로직에서 쿼리를 직접사용하고 있기 때문에, 비즈니스 로직이 복잡해질수록 코드도 복잡해지는 문제가 발생합니다.
4. 객체와 DB 간의 매핑 문제
   SQL 중심설계는, 비즈니스 로직에서 DB의 데이터를 직접 가져오고 그 데이터를 객체에 매핑해 사용합니다. 이때 매핑하는 과정에서도 문제가 발생하게 됩니다. DB와 객체지향 언어사이에는 데이터를 관리하는 방식에 차이가 존재합니다. 이때문에 개발자가 DB데이터를 객체에 맵핑해주는 코드를 직접 작성해야하는 문제가 생깁니다.

🖊 ORM (Object-Relational Mapping)

SQL 중심설계의 문제를 해결하기 위한 방법 중 하나로 ORM을 사용할 수 있습니다.
ORM은 객체와 관계형 DB간의 데이터 매핑을 자동화해주는 프레임워크나 라이브러리를 말합니다. ORM을 사용하게 되면, SQL 중심설계에서 객체와 관계형 DB간의 데이터 관리 방식의 차이로 인한 매핑 문제를 해결할 수 있습니다.
또한 쿼리문을 직접 작성할 필요 없이 객체 지향적 프로그래밍의 특성을 활용해 DB를 제어할 수 있어 가독성과 유지보수성이 증가합니다.

💻 DDD(Domain Driven Design)란?

온라인 서점을 구현하는 상황을 가정해 보겠습니다.
이를 구현하려면, 상품조회, 구매, 결제, 배송 추적등의 기능을 제공해야 합니다. 이 때 온라인 서점은 해결하고자 하는 문제의 영역 즉 도메인(domain)에 해당합니다.

하나의 도메인은 다시 하위 도메인으로 나눌 수 있는데 온라인 서점을 예로 들어보면, 주문, 혜택, 배송, 회원, 카테고리, 리뷰등의 하위 도메인으로 나눌 수 있습니다. 혜택의 하위 도메인은 쿠폰이나 할인과 같은 서비스를 제공하고, 배송 하위 도메인은 배송과 관련된 서비스를 제공합니다.

이렇게 분리한 도메인 중심으로 서비스를 설계한는 방법을 도메인 주도 설계 DDD라고 합니다.
DDD를 사용해 서비스를 설계할 경우 도메인 모델을 우선적으로 고려하기 때문에 비즈니스 로직의 복잡도가 떨어지면 유지보수 또한 쉬워집니다.