입사 후 얼마 되지 않아서 여기저기서 도메인.. 도메인.. 자꾸 눈에 밟혀서 공부를 해야겠다는 생각에 어떤 방법론인가 싶어 정보 조사를 하다가 알게 된 내용에 대해 적어봅니다."
(심지어 그냥 이런 책이 굴러다님)
DDD(Domain-Driven Design, 도메인 주도 설계)란?
DDD(Domain-Driven Design, 도메인 주도 설계)는 비즈니스 도메인(업무 영역)에 집중하여 소프트웨어를 설계하는 방법론입니다. 단순히 코드를 작성하는 것이 아니라, 비즈니스 로직을 명확히 정의하고 모델링하여 코드로 반영하는 것이 핵심
DDD의 목표는 비즈니스 전문가와 개발자가 동일한 언어(Ubiquitous Language)를 사용하여 협업하면서, 도메인의 복잡한 비즈니스 규칙을 잘 반영한 시스템을 만드는 것
DDD의 핵심 개념
DDD는 크게 전략적 설계와 전술적 설계로 나뉨
전략적 설계 (Strategic Design)
도메인을 더 효과적으로 관리하기 위한 큰 그림을 설계하는 단계
Bounded Context (경계 컨텍스트)
• 시스템 내에서 각 도메인의 명확한 경계를 정의하는 개념
• 여러 개의 도메인이 있을 경우, 각각 독립적으로 설계하여 혼란을 방지
• 예를 들면, “상품 관리 시스템”과 “주문 시스템”은 서로 다른 Bounded Context를 가짐
Ubiquitous Language (보편 언어)
• 비즈니스 전문가와 개발자가 동일한 용어를 사용하도록 공통 언어를 정의합니다.
• 예를 들면, “고객이 상품을 구매하면 주문이 생성된다”라는 개념에서 고객, 상품, 주문이라는 용어가 코드에도 반영됨
Context Mapping (컨텍스트 매핑)
• 여러 개의 Bounded Context 간의 관계를 명확히 정의함
• 예를 들면, “주문 서비스”는 “상품 서비스”의 데이터를 필요로 하지만, 직접 참조하지 않고 API를 통해 협력함
전술적 설계 (Tactical Design)
각 도메인 모델을 세부적으로 설계하는 단계임
Entity (엔터티)
• 고유한 식별자(ID)를 가지며 변하는 데이터를 포함한 객체임
• 예를 들면, User(id, name, email), Order(id, items, totalPrice)와 같은 객체가 있음
Value Object (값 객체)
• ID 없이 불변(Immutable) 하며, 동일성보다는 값 자체가 중요한 객체임
• 예를 들면, Money(amount, currency), Address(street, city, zipcode) 등이 있음
Aggregate (애그리게이트)
• 여러 개의 Entity와 Value Object를 하나의 단위로 묶는 개념임
• 특정한 “루트 엔터티(Aggregate Root)”를 통해서만 데이터를 수정할 수 있음
• 예를 들면, Order는 OrderItem을 포함하는 애그리게이트임
Repository (리포지토리)
• 데이터베이스 접근을 추상화하여 엔터티의 저장 및 조회를 담당함
• 예를 들면, OrderRepository.findById(orderId), UserRepository.save(user)와 같은 기능을 제공함
Domain Service (도메인 서비스)
• 특정한 엔터티에 속하지 않지만, 비즈니스 로직을 수행해야 하는 경우 사용함
• 예를 들면, PaymentService.processPayment(orderId, amount)와 같은 서비스가 있음
Application Service (애플리케이션 서비스)
• 도메인 로직을 호출하여 애플리케이션 흐름을 제어하는 서비스임
• 예를 들면, OrderApplicationService.createOrder(userId, productList)와 같은 서비스가 있음
DDD를 사용하는 이유
비즈니스 중심 설계
• 도메인 개념을 코드에 직접 반영하여 개발과 비즈니스를 일치시킬 수 있음
유지보수 용이
• 복잡한 도메인 로직을 구조적으로 정리하여 장기적으로 관리하기 쉬움
대규모 시스템 확장 가능
• Bounded Context를 이용하면 마이크로서비스 설계와도 시너지가 좋음
팀 간 협업 향상
• Ubiquitous Language 덕분에 비즈니스 전문가와 개발자 간 의사소통이 원활해짐
\\\DDD를 적용하기 적합한 경우와 부적합한 경우
적합한 경우
• 복잡한 비즈니스 로직이 많은 시스템 (예: 금융, 이커머스, ERP 등)
• 장기적으로 유지보수해야 하는 대규모 프로젝트
• 도메인 전문가(비즈니스 팀)와 협업이 중요한 경우
부적합한 경우
• 단순한 CRUD 기반 애플리케이션 (예: 블로그, 작은 API 서비스)
• 빠른 MVP 개발이 필요한 경우 (DDD는 학습 비용과 설계 비용이 높음)
결론
DDD는 비즈니스 로직을 중심으로 한 설계 철학입니다. 특히 복잡한 비즈니스 로직을 다룰 때 효과적이며, 팀 간 협업을 강화할 수 있습니다. 하지만, 모든 프로젝트에 적용할 필요는 없으며, 프로젝트의 규모와 복잡도를 고려하여 DDD를 적용할지 결정하는 것이 중요합니다.