DDD 란? 도메인 주도 설계

 

 

 

도메인 중심 설계(Domain-Driven Design)이란?

단순하게 정리하자면 도메인(비즈니스 목표)을 중심으로 잘게 쪼개어 설계(또는 문제 해결)해 나가는 방법이다.

프로젝트 속 모듈간의 의존성은 최소화하며 응집성은 최대화 하면서 말이다...

 

처음 DDD 에 대한 개념을 접할 때는 너무나도 넓은 범위에 난해해서 개념을 이해하기 어려웠었다. 객체지향에 대한 개념을 제대로 이해하지 못했었기 때문일까.

 

객체 지향은 독립적인 개체(객체)들이 상호작용을 통해 발생시키는 이벤트를 목적으로 한다.

 

물건을 사기위해(Buy Domain) 마트에 들어간 A씨는 그곳에서 일하고 있는 B씨에게 계산을 한다(Sell Domain)

점주인 C 는 이를 관리(Manage Domain)한다.

벌써 여기서만 3개 이상의 도메인이 발생했다.

 

우리는 이렇게 발생한 도메인들을 서비스 별로 분리 하는 것을 DDD라 부르기로 했다.

실로 추상적이고 애매하며 난해한 말이 아닐 수 없다. 근데 또 웃긴게 관련된 글을 읽다보면 이게 맞다 ..ㅎㅎ

 

이렇게 어려워 학습비용도 크고, 프로젝트 진행 단계와 관계없이 거쳐야 할 과정도 많은 DDD는 늘 옳은 것일까?

 

'Implementing DDD'의 저자 반 버논은 DDD 도입이 필요하지 않은 경우에 대해서는 다음과 같이 말하고 있다.

당신의 애플리케이션이 완전히 데이터 중심(data-centric)이며 순수한 CRUD 솔루션에 정말 잘 맞아서, 모든 동작이 간단한 데이터베이스 쿼리를 통해 기본적인 생성, 읽기, 갱신, 삭제 등을 수행할 뿐이라면 DDD가 필요하지 않다. 당신의 팀은 그저 예쁜 데이터베이스 테이블 편집기만 있으면 된다. ...... 당신이 단순한 데이터베이스 개발 도구를 사용해 솔루션을 만들 수 있다면, DDD에 회사의 시간과 돈을 낭비하지 말라.

1. 물건을 사기 위해 필요한 정보를 담은 객체와

2. 계산을 하기 위한 정보를 담은 객체

3. 관리를 하기 위한 정보를 담은 객체

 

위 3개의 Repository 를 모두 구현하는 것이 맞을까?

 

 

객체 간 내부 상호작용을 통해(거르고 걸러) 공통 집합을 찾아 Repository로 묶여야만 한다.

오늘 회사에서 집가지 가는 무수히 많은 방법 중 최적의 한 가지 루트를 찾는 네비게이션과 같이 말이다.

 

---

---

📚더 읽을거리

🔗 DDD지향 마이크로 서비스 디자인

🔗 필요한 내용만 추려서 DDD 당장 써먹기

🔗 DDD 핵심만 빠르게 이해하기