일반적으로 데이터를 관계형 데이터베이스를 통해 관리하므로, 데이터베이스 구조와 데이터의 흐름을 중심으로 시스템을 개발하는 것을 일컫는다.
데이터베이스 구조와 데이터의 흐름을 중심으로 시스템을 설계
데이터베이스 설계를 중심으로 개발 프로세스를 진행
데이터베이스 쿼리를 통해 데이터를 처리
객체지향 프로그래밍 언어를 사용하면 불가피하게 객체를 관계형 데이터베이스에 담아 저장하고 관리하여야 하는데, 객체를 데이터베이스에 저장하고 또 다시 꺼내오기 위해서 객체를 테이블로, 그리고 테이블을 객체로 맵핑하는 수고가 필요하다.
게다가 SQL 중심으로 코드를 작성하려면, 객체의 구조를 테이블에 맞춰야만 한다.
따라서 데이터베이스 설계와 개발 프로세스가 밀접하게 연관되기 때문에, 데이터베이스 설계와 개발 프로세스 간의 의존성이 높아지고, 데이터베이스 구조의 변경이 개발 프로세스에 직접적인 영향을 미치게 된다...!
SQL 중심 설계는 데이터베이스 구조와 데이터의 흐름을 중심으로 시스템을 설계하므로, 앞서 말했던 문제점들이 존재한다. 이러한 문제점을 해결하기 위해 DDD(Domain-Driven Design)와 같은 다른 설계 방법론이 등장하게 되었다.
도메인 중심 설계(DDD)는 해결하려는 문제 영역, 도메인을 중심으로 시스템을 설계하는 방법론이다.
그렇다면 도메인이란 정확히 무엇일까? 도메인을 실세계에서 사건이 발생하는 집합이라고 생각하면 쉽다.
배달 서비스를 예로 들면, 가입 점포들을 관리하는 도메인이 있을 수 있고, 손님들이 음식을 주문하는 도메인이 있을 수 있고, 주문 정보를 배달 대행 서비스에 인계하는 도메인 등이 있을 수 있다. 이렇듯 여러가지 도메인들이 서로 상호작용하도록 설계하는 것이 바로 도메인 주도 설계이다.
도메인 모델링을 중심으로 개발
같은 객체가 여러 개 존재할 수 있다 :: 문맥(Context)에 따라 객체의 역할이 바뀐다.
Bounded Context :: 각각의 도메인이 독립적으로 설계되고 구현될 수 있도록, 도메인 모델 별 구역을 나누는 것.
도메인 간 API를 통해 통신 :: 서로 다른 도메인의 경계를 설정하고, 경계를 넘나드는 커뮤니케이션을 최소화
Aggregate(집합) :: 각각의 도메인 영역을 대표하는 객체. 각각의 도메인에 Repository로 묶어야 하는 객체(Entity)가 명확해 질수 있도록 한다.
SQL 중심 설계는 데이터베이스를 중심으로 시스템을 설계하지만, DDD는 도메인을 중심으로 시스템을 설계한다.
SQL 중심 설계는 데이터베이스 구조와 데이터의 흐름을 중심으로 설계하는 반면, DDD는 도메인의 문제 영역을 중심으로 시스템을 설계한다.
SQL 중심 설계는 데이터베이스 정규화를 통해 데이터 일관성을 유지하고, DDD는 도메인 모델을 통해 도메인의 일관성을 유지한다.
SQL 중심 설계는 데이터베이스 쿼리를 통해 데이터를 처리하지만, DDD는 도메인 모델을 통해 비즈니스 로직을 처리한다.
SQL 중심 설계는 데이터베이스 구조가 변경될 때 시스템 전체에 영향을 미친다. 도메인 중심 설계는 도메인 모델이 변경되더라도 시스템의 일부분만 변경된다.
참고 : https://huisam.tistory.com/entry/DDD, https://hudi.blog/problems-sql-centered-development/