Spring boot: DDD(Domain Driven Design)란?

오늘은 DDD 구조에 대해 설명해보고자 한다.

 

처음에 DDD구조를 도입하게 된것은 다름이 아닌,, 회사 기업 프로젝트의 요구사항이었기 때문에 어쩔수 없이 사용하게 되었다ㅠ

처음에는 왜 이런 DDD구조 방식으로 하는지 이해가 가질 않았다. 기존 폴더구조보다 복잡하기만 할뿐 알아보기도 너무 어려웠기에 대체 왜 사용하는지 이해가 가지 않았다. 그래서 DDD의 장점과 단점에 대해 명확하게 이해해보고자 쓰게 되었다.

---

1. DDD란?

DDD란 Domain-Driven Design의 약자로, 소프트웨어 설계와 개발 방법론 중 하나로 주로 복잡한 비즈니스 도메인을 효과적으로 반영하기 위해 도메인 전문가(비즈니스 이해자)와 개발자가 협력하여 소프트웨어의 구조를 설계하는 방식이다.

 

그렇다면 도메인 (Domain)이란 무엇일까

문제를 해결하고자 하는 특정 비즈니스 영역을 말한다. 예를 들어, 은행 시스템에서는 금융 도메인이 될 수 있다. 

또한 도메인을 정할때는 기획단계가 다 끝마친 후에 정해질 수 있다. 필자는 이해 하기 쉽게 도메인 = DB Table 정도로 이해하고 있다.

 

2. DDD Layerd Architecture

어쨌든 DDD 구조는 도메인 주도 설계 방식인데 정확하게는 아래와 같은 계층으로 나누어 설계를 한다.

 

 

1. Presentation Layer (프레젠테이션 계층)

• 사용자와 시스템이 상호작용하는 계층으로, 주로 UI/UX와 관련된 기능을 담당
• 사용자의 요청을 받아 적절한 비즈니스 로직에 전달하고, 그 결과를 다시 사용자에게 보여주는 역할을 담당
• 웹 애플리케이션의 경우, 컨트롤러(controller)나 뷰(view)와 같은 부분이 여기에 해당

역할:

• 사용자의 입력 처리
• 데이터 표현 및 출력

2. Application Layer (애플리케이션 계층)

• 비즈니스 로직을 조정하고, 도메인 계층과 프레젠테이션 계층을 연결하는 역할
• 도메인 객체를 사용하여 특정 작업을 수행하고, 트랜잭션을 관리하며, 애플리케이션의 흐름을 제어
• 주로 서비스(Service)가 위치하며, 이 계층 자체는 비즈니스 규칙을 포함하지 않고 단순히 조정

역할:

• 애플리케이션의 주요 기능을 제공
• 트랜잭션 관리 및 도메인 계층과 상호작용

3. Domain Layer (도메인 계층)

• 애플리케이션의 핵심 비즈니스 로직과 도메인 모델이 위치하는 계층으로, 시스템의 가장 중요한 부분
• DDD의 중심이 되는 계층으로, 엔티티(Entity), 밸류 오브젝트(Value Object), 도메인 서비스(Domain Service), 애그리게이트(Aggregate) 등이 포함
• 이 계층은 비즈니스 규칙과 도메인 모델에 대한 책임을 지며, 인프라스트럭처나 기술적인 세부 사항에 의존하지 않음

역할:

• 비즈니스 로직과 규칙 구현
• 도메인 모델의 상태 관리

4. Infrastructure Layer (인프라스트럭처 계층)

• 데이터베이스 접근, 파일 시스템, 메시징 시스템 등과 같은 기술적 세부 사항을 처리하는 계층
• 외부 시스템과의 통신, 데이터 영속성 관리 등을 담당하며, 주로 리포지토리(Repository) 패턴을 사용하여 도메인 객체의 저장 및 조회를 수행
• 기술적인 관심사를 도메인 계층에서 분리하여, 도메인 모델이 기술 세부 사항에 의존하지 않도록 한다.

역할:

• 외부 시스템과의 통신
• 영속성 관리 (데이터베이스, 파일 시스템 등)

좀 더 쉽게 설명하자면 일반적인 Spring Boot 폴더구조에서 DDD로 변환하게 된다면 다음과 같다.

 

controller -> presentation 폴더

dto, service, serviceImpl -> application 폴더 (비즈니스 로직은 전부 application 폴더에서 작업을 하였다)

Entity, repository -> domain 폴더

jwt, s3, utils, repository 종속성 -> infrastructrue 폴더

 

3. DDD 구조의 장점

1. 비즈니스와 기술 간의 간극을 줄임

• DDD는 개발자와 도메인 전문가가 공유할 수 있는 유비쿼터스 언어(Ubiquitous Language)를 정의하여, 비즈니스 요구 사항이 개발에 명확히 반영되도록 도와준다. 
• 이를 통해, 소프트웨어가 실제로 해결해야 할 비즈니스 문제를 더 정확히 반영할 수 있고, 의사소통 오류를 줄일 수 있다

2. 유지보수성과 확장성 향상

• DDD는 시스템을 도메인 모델을 중심으로 구조화하기 때문에, 각 기능이 잘 정의된 경계(Bounded Context) 내에서 동작한다. 이로 인해 코드의 변화가 한정된 영역에만 영향을 미쳐 유지보수가 더 용이해진다.
• 도메인 객체와 비즈니스 로직이 분리되어 있어, 비즈니스 요구 사항이 변경되더라도 도메인 모델만 수정하면 되며, 애플리케이션 전체를 수정할 필요가 없다.

이외에도 여러 장점이 있지만 내가 실제로 사용하면서 그나마(?) 장점이라고 느낄수 있었던 부분은 다음 두가지였다. 

근데 딱히 장점이라고 느끼진 못했지만..

 

아무튼 도메인간의 높은 응집도와 낮은 결합도로 이루어져있다고 생각하는것이 가장 좋을 것 같다. 

 

4. DDD 구조의 단점

사실 내가 느낀 바로는 단점이 훨씬 더 명확했다..

 

1. 복잡한 폴더 구조

일단 그냥 복잡하다.. 기존 폴더 구조는 도메인 안에 전부 속해서 들어가지만 DDD는 Layer 별로 나누어져있기에 초기 세팅과정이 복잡하고 어렵다

 

2. 불필요한 작업 요구

이건 내가 가장 많이 느꼈던 내용중 하나이다. 프로젝트 규모가 크지 않을경우 굳이 DDD로 개발할 필요성이 없다는 것이다. 유지보수에 특화되어있다는 DDD의 장점이 사라지는것이 특징이다.

 

4. DDD 실제 적용 사례 및 폴더 구조

마지막으로 내가 실제로 DDD로 개발한 폴더 구조에 대해 보여주고 마무리 하겠다. 

 

 

└─fitpet_be
    ├─application
    │  ├─dto
    │  │  ├─request
    │  │  └─response
    │  ├─exception
    │  ├─service
    │  └─serviceImpl
    ├─common
    │  └─config
    ├─domain
    │  ├─model
    │  └─repository
    ├─infrastructure
    │  ├─jwt
    │  ├─persistence
    │  ├─s3
    │  └─utils
    └─presentation
        └─controller