[DDD] DDD란 무엇이고 도대체 왜 쓸까?

큐시즘 30기 스터디 중에서 백엔드 스터디 큐백에 참여하게 되었어요😀

 

각 파트별로 나눠서 공부하게 되었는데 저는 알림파트를 맡았고 첫주에는 DDD에 관해서 스터디를 하고 디렉토리 구조를 만들어 보는 것까지가 과제였어요.

 

지금부터 제가 구글링하면서 찾아본 여러 자료들을 바탕으로 제 방식대로 정리해 볼게요.

 

🤔 DDD란?

• DDD = Domain-Driven Design, 도메인 주도 설계
• 복잡한 소프트웨어 프로젝트의 설계와 개발 과정에서 도메인(문제 영역)을 중심으로 시스템을 구축하는 방법론
• 단순한 소프트웨어 설계가 아닌 모든 구성원들이 함께 해결해나야 할 문제를 정의하고 모델링을 해 나가는 과정
• 문제 영역에 대한 공통된 이해도를 바탕으로 협업 생산성을 극대화하는 것을 목표로 한다.
• 도메인 모델이 비즈니스의 본질적인 규칙과 로직을 반영하고, 이를 기반으로 시스템이 구축이 되어야 한다.

 

😮 기존 구조의 문제점(Feat. Layered Architecture)

1. 수직적 의존 구조로 인한 유연성 저하

• 유저 인터페이스로부터 컨트롤러(또는 리졸버) - 서비스(비즈니스) - 레포지토리 (퍼시스턴스) - 데이터베이스 
• 상위 계층은 하위 계층에 의존하므로, 하위 계층의 변경이 상위 계층에 영향을 미침
• 레포지토리 코드 변경에 따른 비즈니스 로직 수정이 불가피
• 즉, 비즈니스 로직의 유연성을 저하시키고, 변경에 대한 저항성을 증가시킴 

2. 방대하고 모호해지는 서비스 레이어

• 처리해야 할 비즈니스 로직이 많아질 경우, 하나의 서비스 클래스가 광범위한 경계를 다루게 된다.
• 이로인해, 원하는 로직이 어디 있는지 찾기 어렵다.
• 또한 서비스로 묶인 로직들이 서로 실타래처럼 얽힌 참조 관계를 만들고 유지보수가 어렵게 된다.
• 무분별하게 외부 클래스를 주입받아 사용하며 클래스 간 경계가 모호해자며 의존도가 높아진다.

3. 테스트 코드의 신뢰도 저하 및 피로도 발생

• 단위 테스트는 단위별 조직을 격리된 환경에서 테스트할 때 그 진가를 발휘한다.
• 기존 구조는 서비스에 레포지토리 구현체를 주입하여 사용하여 데이터베이스 처리 로직이 변경된다면 비즈니스 로직 단위 테스트도 모두 수정되어야 한다.
• 새로운 무언가를 추가할때 고민하는 시간이 점점 길어지며, 데드 코드도 늘어나고 기능 수정과 커밋에 두려움을 느낌

 

👍 DDD의 효과

1. 비즈니스 요구사항 반영

• 도메인은 소프트웨어가 해결하고자 하는 비즈니스의 영역이다.
• 데이터베이스가 아닌 현실세계 문제점을 세분화된 도메인으로 정의하는데 초점을 맞추어 설계
• 따라서 요구사항에 대해 현실적으로 접근하고 명확하게 정의하게 된다.

2. 협업 효율성 향상

• 모든 구성원들이 공통으로 협의된 언어와 개념을 사용하게 된다.
• 따라서 의사소통이나 개발 방식에서의 통일성을 향상시키는데 큰 도움을 준다.
• ex) 유비쿼터스 언어, 컨텍스트 맵

3. 불필요한 복잡성 제거

• 비즈니스 요구사항을 더 작은 조각으로 나누고 이를 모델링함으로써 시스템이 효율적인 구조를 갖추게 된다.
• 불필요한 복잡성이 늘어나는 것을 사전에 방지하고 모든 팀원이 이해하기 쉽고 유지보수하기 쉬운 시스템을 구축

 

📑 DDD 구성 요소와 원칙

1. 비즈니스 도메인

• 서비스에서 중심이 되는 해결해야 할 문제 영역이다. 
• 이 밑으로는 핵심, 일반, 지원 3가지의 하위 도메인으로 나뉜다.

   1-1 핵심 하위 도메인

• 비즈니스 영역에서 가치를 창출하는 경쟁력의 핵심적인 부분
• 경쟁 우위의 원천이 되며, 복잡성을 지니고, 변동 가능성이 높다.
• 제품 또는 서비스 발명이나 최적화 비용 절감 등이 해당된다.

   1-2 일반 하위 도메인

• 표준화되고 범용적인 기능을 담당하는 영역
• 대부분의 회사가 유사한 방식으로 동일하게 수행하며 복잡성을 높으나 핵심 가치와 연결은 X
• 본인인증, 소셜 로그인, 인가 로직이 포함된다.

   1-3 지원 하위 도메인

• 핵심 하위 도메인을 지원
• 비즈니스에서 중요한 역할을 하면서도 그 자체로는 비즈니스의 핵심 가치를 생성하지 않는다.
• API 호출, 알림이 포함된다.

2. 유비쿼터스 언어

• 요구 사항과 시스템 설계를 소스 코드로 옮기는 과정에서 정보의 손실 및 왜곡을 방지하기 위한 대안
• 엔지니어링 언어가  아닌 비즈니스 언어로 구성되어 모든 구성원들이 공통된 이해를 가져야 한다.
• 일관성있고 모호함을 제거한 상태로 정의한 유비쿼서스 언어 사전을 통해 지속적으로 발전시켜야 한다.

3. 바운디드 컨텍스트와 컨테스트 맵

• 바운디드 컨텍스트는 유비쿼터스 언어를 여러 개의 작은 언어로 나누고, 각 언어를 적용할 수 있도록 명시적으로 경계를 만든 것.
• 이러한 바운디드 컨텍스트 간의 관계를 표현한 것이 컨텍스트 맵이다.
• 하위 도메인의 경우 비즈니스 전략에 의해 정의되기에 도메인 분석 단계에서 식별되자만, 바운디드 컨텍스트는 소프트웨어 설계에 직접 반영되기 때문에 소프트웨어 엔지니어가 설계한다.
• 이벤트 스토밍 기법을 통해 설정할 수 있다.