DDD( Domain Driven Design )

Domain이란?

개념적으로는 '영역'을 말한며 , 소프트웨어로 구현하고자 하는 문제 영역이라고 할 수 있다.

맛집 공유 애플리케이션을 예를 들면 

• 맛집 정보를 저장하는 회원 
• 맛집으로 저장되는 음식점 
• 자신의 맛집을 다른 회원과 공유하는 과정

이들을 가각의 도메인 이라고 부를 수 있다.  

 

 

DDD( Domain Driven Design )

만들어진 계기는 일방향적인 소통과 개발에서 출발한다.

1. 도메인 전문가들이 도메인을 추상화해서 모델을 추출,설계한다.
2. 개발자들은 모델만을 보고 소프트웨어를 실체화한다.

위 과정에서의 문제점은

도메인 전문가들은 개발자들을 생각하지 않고 복잡하게 도메인을 짠다 -> 소프트웨어의 복잡성 높아진다.

개발자들은 모델을 만든 도메인 전문가들의 의도를 모른 상태로 소프트웨어를 만든다 -> 도메인에 대한 이해가 부족해 실제 소프트웨어와 도메인 간의 불일치가 일어난다.

 

이런 문제들을 방지하기 위해 개발자와 도메인 전문가들이 둘다 이해할 수 있는 언어인 공통의 언어(유비쿼터스 언어)를 사용하여 기획부터 개발까지 이르는 길을 구체화 시키는 과정에 모두가 참여하여 도메인과 소프트웨어가 항상 함께 움직이는 구조의 모델, 결합도는 낮고 응집력은 높은 모델을 만드는 것이 DDD의 핵심이다.

 

기술적인 부분에서 설명을 하면 , 각각의 기능적인 문제의 영역을 정의하는 도메인과 그 도메인을 사용하는 비즈니스 로직을 중심으로 설계하는 것이라 할 수 있다. 그 과정에서 Aggregate , bounded context , context map 등의 개념이 사용된다.

 

+ SQL 중심 설계와  DDD의 차이점

SQL 중심 설계란

사람들은 데이터를 저장하기 위해 관계형 DB를 사용한다. 필요에 의해 NoSQL같은 DB를 사용하기도 하지만 대부분의 경우 관계형 DB를 사용한다. 그리고 관계형DB가 알아들을 수 있는 것은 SQL뿐이기 때문에 이를 중심으로 개발을 하는 것이 SQL 중심의 설계다. 

 

DDD와 SQL 중심 설계의 가장 큰 차이는 "객체지향"과 어울리냐이다.

SQL 중심 설계의 경우 객체를 관계형 데이터베이스에 저장하고 꺼내오기 위해서는 객체를 테이블로, 테이블을 객체로 매핑하는 추가적인 작업이 필요하다 , 또한 데이터베이스에 테이블을 하나 말들더라도 CRUD쿼리를 다 짜야하는 등 반복적인 작업을 해야한다.

반면 DDD의 경우 도메인는 하나의 도메인 안에서도 bounded context라는 개념으로  영역의 관심사를 분리하고 , 영역의 책임을 명확히 하여 결합도를 낮추고 응집력을 높인다. 이는 "객체지향"이 추구하는 바와 같기 때문에 확실히 SQL보다 DDD가 객체지향과 잘 맞는다고 할 수 있을 것 같다.