DDD(Domain-Driven Design) 레이어드 아키텍처

DDD(Domain-Driven Design)

DDD는 도메인 주도 설계(Domain-Driven Design)의 약자로, 복잡한 소프트웨어 시스템을 구축할 때 도메인에 초점을 맞춰 설계하는 방법론이다. 이를 통해 소프트웨어가 비즈니스 도메인을 정확하게 반영하고, 개발자와 도메인 전문가 간의 소통을 원활하게 할 수 있다.

도메인이란 문제 영역 또는 비즈니스 영역을 가리킨다. 예를 들어, 은행 시스템에서는 계좌, 고객, 거래 등이 도메인이다.

DDD의 계층 구조

DDD에서는 주로 아래와 같은 계층으로 시스템을 구성한다.

이미지 출처: https://anymindgroup.com/news/tech-blog/13581/텍스트

표현 계층은 응용 계층에 의존적이고, 응용은 도메인에, 도메인은 인프라 스트럭처에 의존한다.
상황에 따라 상위 계층이 하위 계층에 의존하지 않을 수 있지만, 하위 계층은 상위 계층을 의존하지는 않는다.

• 표현 계층(Presentation layer): 사용자의 요청에 대해 해석하고 응답하는 일을 책임지는 계층 (Controller)
  • Client로부터 request를 받고 response를 return 하는 API를 정의
• 응용 계층(Application layer): 비즈니스 로직을 정의하고 정상적으로 수행될 수 있도록 도메인 계층과 인프라스트럭처 계층을 연결해주는 역할을 하는 계층 (Service)
  • transaction 관리, DTO 변환, 모듈간의 연계를 진행합니다.
• 도메인 계층(Domain layer): 비즈니스 규칙, 정보에 대한 실질적인 도메인에 대한 정보를 가지고 있으며 이 모든것을 책임지는 계층 (Model)
  • Entity를 활용하여 도메인 로직이 진행되고, 업무 상황을 반영하여 상태를 제어하는 역할에 집중하는 계층
• 인프라스트럭처 계층(Infrastructure layer): 외부와의 통신(ORM, DB, NoSQL)을 담당하는 계층 (Repository)
  • 해당 계층에서 얻어온 정보를 응용 계층 또는 도메인 계층에 전달하는 것을 주 역할로 담당

DDD의 장단점

장점:

• 도메인 모델의 명확성: 비즈니스 요구사항을 반영하고, 이해하기 쉬운 도메인 모델을 만들 수 있다.
• 비즈니스 로직 중심: 비즈니스 로직을 중심으로 설계되어, 개발자와 도메인 전문가 간의 소통을 원활하게 한다.
• 유연성: 변경에 대한 대응력이 뛰어나며, 비즈니스의 변화에 따라 시스템을 쉽게 수정할 수 있다.

단점:

• 추가적인 복잡성: DDD를 적용하면 추가적인 추상화와 계층이 필요할 수 있어 시스템이 더 복잡해질 수 있다.
• 적용 범위의 한계: 모든 프로젝트에 DDD를 적용하는 것이 항상 적절하지는 않을 수 있다. 특히 작은 규모의 프로젝트나 단순한 비즈니스에는 과도한 비용과 복잡성을 초래할 수 있다.