DDD(Domain-Driven Design)와 SQL-DD (Structured Query Language-Driven Design)는 소프트웨어를 개발하는 여러 방법론중 일부이다.
이름으로 유추할 수 있듯 두 방식은 설계할 때부터 접근방법이 다르다.
DDD (Domain-Driven Design)
도메인이란 특정 분할된 업무 분야나 문제 영역을 뜻하며 비슷한 업무들의 집합으로 분류될 수 있다. 특정 임의의 개념으로 나누거나 개념들 사이의 관계 또한 포함하고 있는 개념이다.
예를 들어, 어떤 교육을 진행한다고 가정할 때 선생과 학생이라는 개념이 포함된다.
학생은 강의를 듣고, 수업을 듣고, 과제를 제출한다.
선생은 강의를 개설하고, 수업을 진행하고, 과제를 채점한다.이 경우 도메인은 강의, 수업, 성적을 도메인으로 볼 수 있으며 모두 선생과 학생이라는 도메인의 관계도 포함하고 있다.
위의 설명처럼 DDD 는 좀 더 객체지향에 가깝다고 생각해볼 수 있어서 자주 쓰이는 방법론중 하나이다.
(이런 개념까지 나온 이유는 아마도 구현하려는 서비스의 개념자체가 복잡할 경우, 최대한 구현하려는 사람이 편하기위해, 실수를 줄이기 위해, 유지보수가 편하기 위해 고안된 방법이라고 생각한다.)
이름에서 나타나듯 도메인을 중심으로 설계하고 디자인하여 도메인들끼리의 조합을 통해 시너지를 내며 최종 결과의 복잡성을 줄이고 유연성을 높여 유지보수를 용이하게 할 수도 있다.
이를 가능하게 하기 위해서 핵심은 크게 3가지로 나눌 수 있다.
1. 핵심 도메인을 나누고 해당 도메인에 집중
2. 각각의 도메인을 정교하게 구축하고 세분화
3. 해당 도메인의 문제를 해결할 수 있는 전문가와 적극적인 협업
이를 가능하게 하기 위해 DDD는 전략적(Strategic)설계와 전술적(Tactical)설계로 나뉜다.
- 전략적 설계(Strategic Design)
모델과 바운디드 컨텍스트를 나누는 설계이며 협업을 위한 유비쿼터스 언어의 정리도 포함된다.
개념을 코드로 구현하기 전에 모델들 사이의 상호작용을 고려하여 인터페이스 등을 정의하거나 전체적인 흐름을 파악하고 경계를 나누며 여러 문제를 명확히 이해할 수 있도록 하는 과정이다. - 전술적 설계(Tactical Design)
세부 아키텍처, 코드의 구현과 관련된 부분이며 전략적 설계(Strategic Design)에서 나뉜 경계와 모델 등을 유지보수성과 확장성을 고려하여 코드를 구성하는 등의 작업과정이다.
데이터 흐름 등을 고려한 세부적인 설계를 수행하고, 구현 과정에서 발생할 수 있는 다양한 문제들을 해결하고 코드의 유연성과 유지보수성을 보장하는 과정이기도 하다.
이 방식으로 설계하기 위해, 또는 설명하기 위해서 여러가지 개념들이 포함된다.
모델
모델이란 도메인에 대한 이해와 복잡성을 해결하기 위해 해당 도메인의 규칙, 개념, 프로세스 등을 포함하는 추상적 개념이다.
모델은 다른 모델과의 경계가 확실해야하며 소프트웨어 개발자와 해당 도메인의 전문가가 같이 구축해 나가는 개념이다.
예를 들어 위 예시에서 학생과 선생으로 클래스로 나눌 수 있다.
학생은 이름, 학번, 수강과목 등의 속성을 가지고 선생은 수업을 개설할 수 있으며 때에 따라 휴강할 수 있는 동작도 정의할 수 있다.
즉, 객체지향적인 관점에서 소프트웨어를 개발하기 위해 현실 세계의 개념을 객체로 추상화된 개념으로 정의할 수 있다.
바운디드 컨텍스트 (Bounded Context)
위 모델을 하나의 경계로 묶는 개념이다. 때문에 하나의 논리적인 모델을 갖는 것이 일반적이다.
바운디드 컨텍스트는 보통 용어를 기준으로 구분하며 실제로 다른 패키지에서 개발되는 코드라면 다른 바운디드 컨텍스트를 갖는다고 할 수 있다.
바운디드 컨텍스트에서 개발할 때 주의할 점은 모델이 섞이지 않도록 하는 것이다. 바운디드 컨텍스트는 서로 다른 패키지에서 개발하고 서로의 영역이 명확해야 한다.
유비쿼터스 언어 (Ubuquitous Languege)
개발자와 도메인 전문가와의 정확하고 효율적인 협업을 위해 공통된 용어를 정의하거나 개념을 정리하는 것을 뜻한다. 예를 들어 위 예시에서 선생이 아니라 강사라고 지칭한다면, 도메인 전문가는 시간제 강사로 오해할 수 있는 여지가 충분하기에 정확이 문제를 해결하기 위한 언어라고 할 수 있다.
용어뿐만이 아니라 ERD, 다이어그램, 유스케이스 또한 포함될 수 있다.
도메인 모델 패턴
어떤 서비스의 수행 패턴을 말하는데 객체지향적으로 위에서 정의된 모델과 바운디드 컨텍스트 등의 규칙/개념 등을 구현하거나 처리하는 패턴이다.
일반적으로 크게 4가지의 계층으로 나뉜다.
- Presentation(표현)
사용자의 요청을 처리하고 사용자에게 정보를 보여준다 - Application(응용)
사용자가 요청한 기능을 실행한다
업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다 - Domain(도메인)
시스템이 제공할 도메인의 규칙을 구현한다 - Intrastructure(인프라 구조)
외부 시스템과의 연동을 처리한다(DB, Messaging 등)
SQL-DD (Structured Query Language-Driven Design)
말그대로 데이터베이스의 설계에서 시작되는 소프트웨어 개발 방법론 중 하나이다.
데이터베이스에 대한 전문적인 지식이 있다면 도메인 모델과 관계형 데이터베이스 간의 일관성을 유지하여 도메인 모델링과 관계형 데이터베이스 설계 간의 간극을 줄이는 것이 가능하며 이것이 곧 목적이기도 하다.
역정규화 (Denormalization)
SQL-DD에서 중요한 개념인 역정규화는 도메인 모델에 따라 데이터베이스 스키마를 수정되는것을 의미한다. 이를 통해 도메인 모델과 데이터베이스 간의 일관성을 유지한다.
데이터베이스의 스키마에서 도메인이 가지고 있는 개념도 포함되어 있기 때문에 개발속도를 높이는데도 이점이 있으며 SQL 쿼리문을 간단하게 수정될 수 있어 가독성을 높일 수 있다.
생산성과 이식성
직관적인 SQL 구문을 사용하여 테이블 구조를 정의하고 데이터베이스를 구축할 수 있기에 빠른 개발이 가능해서 생산성이 높아진다.
또한 데이터베이스를 사용한다는 것은 추상적인 개념 위주 대신 직관적인 데이터를 위주로 개발할 수 있기 때문에 데이터베이스 유지보수에 이점이 있다.
업무 로직 변경 등으로 인한 데이터베이스 변경이 필요할 때도 비교적 빠른 수정이 가능하다.
또한 SQL 쿼리문은 대부분의 DBMS에서 지원하기 때문에 이식성이 뛰어나다.
때문에 다른 데이터베이스 구조나 특성, 쿼리 구문을 일일히 수정하지 않고 마이그레이션을 할 수 있다.
왜 DDD보다 안쓰이는가?
요즘 소프트웨어 개발의 패러다임은 당연히 객체지향이다.
근데 SQL-DD는 데이터베이스와의 너무 높은 결합도를 가지고 있기에 객체지향의 장점인 확장성과 유연성에 방해가 될 수 있다.
성능이슈
역정규화로 성능을 높이기 때문에 중복된 코드의 양이 늘어나거나 데이터 무결성을 저해할 수 있다. 때문에 데이터 일관성, 코드 컨벤션의 유지가 어려워지는 등의 유지보수의 문제와 더불어 그에 따라 성능에 악영향을 피할 수 없는 경우가 발생할 수 있다.
유지보수
SQL-DD는 데이터 모델링과 구현에 집중된 방법론이기에 서비스가 동적인 변화가 잦다면 대응하기 어려울 수 있다.
예를 들면, 위 도메인 예시에서 학생, 선생 이외에 강사, 교환학생 등의 도메인이 추가된다면, 새로운 데이터베이스 스키마가 필요하고 그로 인해 관련된 모든 쿼리문의 수정이 불가피할 경우가 생긴다.
DDD vs SQL-DD
그래서 SQL-DD가 무조껀 안좋을까? 상황에 따라 다르다고 생각한다.
DDD는 엄청 복잡한 서비스라고 할지라도 도메인별로 모델 등을 분류함으로써 개발자 입장에서 해당 도메인에만 집중할 수 있으며 유지보수가 쉬워진다.
SQL-DD는 규모가 작은 프로젝트라면 더 빠르고 데이터베이스의 구조로 전체적인 흐름을 DDD보다 더 빠르고 쉽게 파악이 가능할 수 있다.
데이터베이스의 구조를 명확하게 정의하고 데이터의 일관성을 유지하는 방법이기에 버그나 예기치 못한 상황을 방지하기 더 편할 것이다.
DDD는 도메인에 대한 이해가 확실해야 할 뿐더러 SQL-DD보다 조금 더 복잡한 방법론이기에 복잡성을 해결하기엔 효율적이나 설계 단계에서 오랜 시간이 걸릴 수 있다.
때문에 많은 비용도 감수해야할 상황이 생길 수 있으며 작은 규모의 프로젝트에서는 오히려 더 복잡해지는 상황이 생길 수 있다.
하지만 SQL-DD는 데이터 중심 설계를 통해 이미 개발 단계에서 바로 적극적인 데이터 활용으로 빠른 생산성을 가지기에 작은 규모에서 더 유리할 것이다.
즉, 작은 규모의 사이즈에선 SQL-DD가, 큰 규모와 높은 복잡성을 가진다면 DDD가 효율적이라고 생각한다.
