BackEnd/DDD

DDD란 무엇인가(1)

hyunki.Dev 2022. 10. 23. 16:54

DDD(Domain Driven Deisign)의 간단 소개

 지난해부터 회사에서 진행하는 차세대 프로젝트에 참여하고 있습니다. 해당 프로젝트의 주요 업무는 MSA와 DDD를 활용해 클라우드 환경으로 모놀리식 시스템을 마이그레이션 하는 것입니다. 이때 자연스럽게 MSA 뿐만 아니라 DDD 용어에 대해 많이 접하고 있습니다. 그래서 오늘은 해당 개념에 대해 정리하고자 이 글을 작성하게 되었습니다. 

 

 우선 DDD는 간단하게 정의내리자면 단순한 코딩/아키텍처 구성 방법이 아니라 패턴, 아키텍처 설계 등을 모두 합친 개발의 새로운 패러다임이라고 볼 수 있습니다. 사실 해당 용어는 실무에서 일하시는 분들도 백엔드 개발자가 아니거나 최신의 트렌드를 자주 접할 수 있는 직무가 아닌 레거시 시스템을 주로 운영하고 개발하는 분들이라면 접하기 힘들 수도 있습니다. 저 또한 차세대 프로젝트에 투입되기 전 학교나 대외활동에서 프로젝트를 진행할 때에는 접해 보지 못했습니다. 

 

그런데 최근에는 대기업, 빅테크 기업등에서 MSA 즉, 마이크로서비스 아키텍처를 도입하려 하거나 이미 도입하여 해당 아키텍처를 활용하고 있고 이러한 MSA 구조에서 DDD는 자연스럽게 따라오는 개발 패러다임이기에 점점 많은 분들이 접할 기회가 많아지고 있습니다. 

 

우리가 흔히 개발을 하면서 겪게 되는 어려움에는 크게 두 가지가 있습니다.

  1. 사용자(고객, 현업)에서 제시하는 복잡하고 자주 변화하는 요구사항
  2. 성능이나 협업 중 발생하는 기술적인 어려움

 DDD는 이 중에서 주로 1번의 어려움에 대한 해결에 초점을 맞춘 방법론이라고 할 수 있습니다. 기획자(도메인 전문가)들의 요구사항을 개발 언어로 변환하는 '비효율'최대한 '효율'적으로 바꾸려는 통찰이 집약된 방법론입니다. 그러나 DDD는 그 필요성이 크지 않은 상황이라면 도입하는 것에 너무 큰 비용이 들게 됩니다. 학습해야 할 것도 많고, 거쳐야 할 과정도 복잡하기 때문입니다. 그래서 보통 MSA로 자신들의 서비스를 전환하고 싶어하는 회사에서 주로 선택하고 있습니다.

 

실제로 Implementing DDD의 저자 반 버논은 DDD 도입이 필요하지 않은 경우에 대해 다음과 같이 언급하고 있습니다.

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

 

 그러므로 단순히 최신트렌드라서 요즘 다들 그렇게 해서 해당 방법론을 채택하고 활용하는 것은 큰 패착으로 이어질 수 있습니다. 

DDD는 복잡하고 급변하는  비즈니스 상황 또는 고객들의 요구사항에 빠르게  문제를 해결하기 위해 사용할 수 있는 방법론이지만 어디까지나 현재 자신의 비즈니스 상황 ,비즈니스 프로세스, 현재 운영하고 있는 시스템에 맞게 도입여부를 검토해야 합니다. 


DDD 적용 과정

DDD는 간단하게 말하면 비즈니스 Domain별로 나누어 설계하는 방식입니다. 이러한 방식의 설계가 수많은 검토에도 불구하고 DDD를 도입하는 것이 우리 비즈니스에 이득이 된다고 판단이 되었다면 아래의 과정을 거치면 DDD의 적용을 시작해야 합니다.

  1. DDD에서 말하는 도메인/서브도메인/바운디드컨텍스트를 이해하고 비즈니스를 구분하고 정의하기
  2. 이를 바탕으로 Aggregate/Entity/Value Object/Repository 등을 구현하기
  3. 이에 적합한 개발 아키텍처를 결정하고 개발하기 
  4. 그리고 팀 구성원이 모두 이에 대한 합의를 이루어야 하고, DDD에 대한 지식들이 학습되어 있어야 한다.

지금 제가 참여하고 있는 프로젝트에서도 한 스프린트 내내 1번과 2번의 협의 과정을 거치고 있을 정도로 해당 부분에 대한 합의가 쉽게 이루어지지 않는 것 같습니다. 비즈니스를 어떻게 도메인을 규정짓고 나누냐에 따라 충분히 달라질 수 있기 때문입니다.

 


DDD 와 개발 방법론의 관계

에릭 에반스의 'DDD' 저작 이후로 시대가 지나면서 다음과 같은 기술들과 아키텍처들이 화두에 오르기 시작했습니다.

MSA, Hexagonal Architecture, CQRS Patterns, Event-Driven, Event-Sourcing

DDD는 위와 같은 패턴/아키텍처들과 조합되었을 때 많은 시너지가 나는 방법론입니다.

반 버논의 'Implementing DDD' 에서는 실제로 위의 방법론들에 대한 대략적인 소개와 DDD에서 활용 가능성에 대해서 소개해 줍니다.

 

최근 핫하다고 불리는 방법론들과의 통합이 잘 이루어지고 현업 비즈니스의 복잡성 문제까지도 해결해줄 수 있는 방법론.

이 정도라면, 딱히 필요하지 않더라도  백엔드 개발을 하고 있다면 한 번은 공부해 볼만할 것 같습니다.


기존 코드 vs DDD

DDD 는 데이터 중심의 설계에서 벗어나는 것으로 기존코드들과 다음에 있어서 차이를 보입니다.

데이터 중심의 코드에서는 보통 다음의 패턴으로 개발이 많이 이루어집니다.

 

public void createReservation(User user, Seat seat, LocalDateTime startTime, LocalDateTime endTime){
    Reservation reservation = new Reservation();
    reservation.setUserId(user.id);
    reservation.setSeatId(seat.id);
    reservation.setStartTime(startTime);
    reservtiion.setEndTime(endTime);
    this.reservationRepository.save(reservation);
}

위의 코드는 Getter 와 Setter를 이용해서 비즈니스 로직을 처리하고 있습니다. 그러나 DDD에서는 @Setter 어노테이션을 활용하지 말 것을 권고합니다. 위와 같은 코드를 'Anemic Domain Model(무기력증에 걸린 도메인 모델)'이라고까지 부르면서 경계하고 있습니다. DDD에서는 위와는 다르게 Entity에 직접 영향을 미치는 코드를 도메인 영역이라는 부분으로 감춰버린다. 그럼으로서 코드의 흐름을 이전과 다르게 더 직관적으로 개발자들이 읽을 수 있도록 도와주기도 합니다.

public void makeReservation(User user, Seat seat, LocalDateTime startTime, LocalDateTime endTime){
    this.reservationCommandService
        .makeReservation(user, seat, startTime, endTime);
}

 

만약에 예약 시간을 변경해야 한다면 기존에는 @Setter를 활용하여 다음과 같이 코딩했을 것입니다.

reservation.setStartTime(start);

 

하지만 DDD에서는 아래와 같은 인터페이스를 두고 시작 시간을 변경하고자 할 것입니다.

public interface Reservation{
    public void changeStartTimeTo(LocalDateTime start);
}

reservation.changeStartTimeTo(start);

 

이와 같이 DDD를 적용하면 코드에 대한 가독성과, 로직의 흐름을 직관적으로 파악하는 데에 도움이 됩니다. 

이는 객체지향('실제로 존재하는 객체'가 어떤 행위를 하는 것처럼 구성하는 방법론)을 그대로 구현해 낸 것으로 볼 수 있습니다.  

 

DDD는 실제로 일어나야 하는 과정을 자세하게 설명해 주는 데에 능한 방법론입니다. 도메인 지식이 적은 사람이 코드를 봤을 때,

메서드 이름만으로 무엇을 하는지 바로 알 수 있을 정도가 되도록 하는 것이 DDD 지향적인 코드의 장점입니다.

 

하지만 앞서 말씀드렸듯이 DDD는 무적이 아닙니다. 충분히 좋은 대안들이 있을 수 있으며 어디까지나 현재 비즈니스 상황을 고려하여 도입이 검토되어야 하는 개발 방법론 중 하나라고 보시면 될 것 같습니다.

 

 

 

참고 : https://appleg1226.tistory.com/40?category=1008265#recentEntries 

 

(1) DDD란 무엇인가 - 데이터 중심 개발과 도메인 중심 개발

참고로 스터디는 다음의 책을 통해서 진행했다. DDD 간단 소개 우선 DDD(Domain-Driven Design)에 대해서 간단하게 소개를 하자면 다음과 같다. DDD는 단순한 코딩/아키텍처 구성 방법이 아니다. 즉 패턴

appleg1226.tistory.com

책 : DDD START! , 마이크로서비스 도입 이렇게 한다