[설계 이야기] DDD 도입일지

딩동 Github
딩동 Behance

디프만에서 딩동 프로젝트를 시작할 때 개발 생산성 향상을 위해 도메인 주도 설계(이하 DDD)를 도입헀다. 하지만, 충분한 사전 공부와 지식이 없는 상태에서 무작정 진행하다 보니 어려움을 겪었고 이를 계기로 확실하게 공부하고 실제 설계 과정을 통해 정리해보는 시간을 가져보려 한다.

DDD란?

도메인(현실세계에서 벌어지는 문제)을 중심에 놓고 설계하는 방식

=> 즉, 서비스에서 다루는 도메인들끼리의 상호작용과 제약사항들을 중심으로 설계하는 방식이다.

전술적 패턴, 전략적 설계

DDD를 도입하면서 가장 큰 실수는 하나의 전술적 패턴으로써만 이해한 것이다. 도메인 주도 설계 이름에서 볼 수 있듯이 설계 방식이지 패턴으로써만 접근하면 안되는 것이다. DDD에서 제시하는 설계 방법들을 통해 하위 도메인 내 Bounded-Context를 구체화하고 각 Bounded-Context 간 관계와 역할을 설정하고 전술적 설계를 진행하는 것이 이상적이다.

전략적 설계 과정

• 우선 서비스의 비즈니스 도메인 내에서 문제 도메인을 식별한다.
  

• 유비쿼터스 언어를 이용한 도메인 지식 탐구를 통해 식별한 문제 도메인을 하위 도메인으로 나누면서 문제 공간을 도출한다.

  문제 공간 도출 목적: 팀에서 가장 우선순위를 높이고 리소스를 많이 투자해야 할 도메인을 식별해야 하기 때문에 하위 도메인을 식별하는 과정이 필요하다.

• 유비쿼터스 언어를 이용한 도메인 지식 탐구를 통해 도메인 문제 공간의 하위 도메인 별 Bounded-Context를 식별하고 각 Bounded-Context간 관계와 전술을 선택하며 해결 공간을 도출한다.

  해결 공간 도출 과정에선 Bounded-Context간의 관계와 규칙을 정하고 전술적 접근이 필요하기 때문에 도메인 지식 탐구 과정에서 도메인 전문가 (기획자)보다 개발자의 역할이 더 중요하다.

유비쿼터스 언어의 중요성

• 기획자와의 지식 탐구, 회의 과정에서 각자 사용하는 용어의 차이가 있다면 커뮤니케이션에 어려움이 발생한다.
• 도메인에서 사용하는 용어를 코드 상에 반영하지 않으면 다른 팀원이 코드를 읽을 때 어려움이 발생한다.
• 사용자와 개발자가 말하는 용어가 다르면 피드백 과정에서 어려움이 발생한다.

=> 기획자, 사용자, 개발자가 같은 용어를 사용할 수 있도록 유비쿼터스 언어의 사용이 중요하다.

전술적 패턴 도입

Layer Architecture 설계

• Application Layer, Core Layer, Domain Layer, Infrascructure Layer로 구성
• 멀티 모듈 구성

Aggregate

• 문제 도메인 내 하위 도메인 기준으로 Aggregate 정의
• 타 Aggregate 도메인과 매핑 시 연관관계 제거 및 도메인 서비스 레이어 이용

Entity와 VO

• 각 Bounded-Context는 기본적으로 Entity로 생성
• 1:1 매핑 가능한 경우 캡슐화를 위해 Embedded Vo로 분리

Adaptor

• Repository 인터페이스를 DI받는 Adaptor 생성
• 각 서비스 레이어에서 사용하는 쿼리 메서드들을 모아서 중복 코드 감소를 위해 사용

도메인 간 룰 정의

• 각 도메인 간 룰들을 정의하여 Validator 생성
  • 유저는 '행성'의 '주민'으로 가입하여 서비스를 이용할 수 있다.
  • '행성'의 '주민'은 '주민증'을 통해 자기소개를 할 수 있다.
  • '행성'의 '주민'은 '주민증'을 생성해야 '댓글', '콕찌르기' 등 서비스를 이용할 수 있다.

전략적 설계 도구

• Use-Case 분석 (Top-Down)
  • 서비스 설계 단계에서 도메인 전문가 (기획자)와의 회의와 요구사항 정의서, 기능 설계서 등을 통해 Bounded-Context를 도출해내는 방법
• Event Storming (Bottom-Up)
  • 추상적인 도메인 이벤트로부터 Bounded-Context를 도출해내는 방법

딩동 프로젝트는 팀원간 회의와 요구사항 정의서, 기능 설계서를 통해 분석하고 설계하는 Use-Case 분석법을 사용했다.

결론

공부하고 이해한 후 DDD를 적용해보면서 훨씬 체계적이고 효율적인 설계를 할 수 있었다. 물론, 우리 서비스와 같은 규모가 작은 프로젝트에서 DDD를 적용하는건 리소스 낭비일 수도 있다. 하지만, 설계 방식을 적용하고 전술적 패턴까지 도입해보면서 더 깊게 이해한 경험이 되었다.

Ref.

https://learn.microsoft.com/ko-kr/azure/architecture/microservices/model/tactical-ddd
https://incheol-jung.gitbook.io/docs/q-and-a/architecture/ddd