밤빵's 개발일지
[TIL]20241215 DDD 이해하기 본문
도메인 주도 설계(Domain-Driven Design, DDD)는 비즈니스 도메인을 깊이 이해하고 코드 설계에 적극 반영하는 개발 방법론이다. 단순히 기능 구현에만 초점을 맞추는 것이 아니라, "도메인 전문가와 협력하여, 도메인의 개념을 코드 구조와 언어에 녹여내는 것"을 목표로 한다. 코드와 비즈니스 로직이 일관된 모델을 가지며, 변화하는 요구사항에도 유연하게 대응할 수 있다. 나는 이전에 "도메인이라는 개념은 무엇인가?"라는 주제로 개발일지를 작성한 적이 있는데, 도메인을 "문제를 풀기 위해 설계된 소프트웨어의 특정 영역"으로 이해하려고 노력했다. 하지만 이번에는 한 단계 더 확장해서 DDD라는 개념을 학습하며, 도메인이 소프트웨어 개발에서 어떤 역할을 하는지 더 깊이 이해하려고 한다.
DDD의 핵심 개념
DDD는 몇 가지 핵심 개념을 중심으로 설계된다. 이 개념들을 이해하고 적절히 활용하는 것이 중요하다.
1. 유비쿼터스 언어(Ubiquitous Language)
유비쿼터스 언어란, 개발자와 도메인 전문가가 공유하는 공통의 언어를 의미한다. 비즈니스에서 사용되는 용어를 코드에 그대로 반영하고, 의사소통의 단절을 줄이면서 모델과 실제 도메인을 일치하도록 만든다. 전자상거래 시스템에서 주문(Order), 고객(Customer), 배송(Delivery)과 같은 용어를 그대로 코드에 반영한다.
2. Entity와 Value Object
Entity
고유 식별자를 가지며, 상태가 변할 수 있는 객체이다. 전자상거래의 Order는 고유 ID를 가지며, 상태(주문 완료, 배송 중 등)가 변경될 수 있다.
Value Object
고유 식별자가 없으며, 불변성을 가지는 객체이다. Address는 "서울시 강남구"라는 값을 가지는 객체로, 같은 값이면 동일하다고 간주된다.
3. 애그리게이트와 루트 엔티티
애그리게이트
관련된 객체를 하나로 묶은 집합이다. Order는 주문 항목(Order Item)이라는 객체 집합을 포함한다.
루트 엔티티
애그리게이트의 진입점 역할을 하며, 외부에서 애그리게이트를 조작할 때 루트 엔티티를 통해 접근한다.
4. Repository
리포지토리는 엔티티를 저장하고 검색하는 인터페이스를 제공한다. 데이터 저장소와 도메인 로직이 분리된다.
예시 코드로 DDD 이해하기
전자상거래의 Order를 중심으로 DDD 개념을 코드로 구현했다.
Entity
public class Order {
private Long orderId;
private List<OrderItem> orderItems;
private OrderStatus status;
public Order(Long orderId) {
this.orderId = orderId;
this.orderItems = new ArrayList<>();
this.status = OrderStatus.PENDING;
}
public void addItem(OrderItem item) {
orderItems.add(item);
}
public void completeOrder() {
this.status = OrderStatus.COMPLETED;
}
public Long getOrderId() {
return orderId;
}
public List<OrderItem> getOrderItems() {
return orderItems;
}
}
Value Object
public class OrderItem {
private String productName;
private int quantity;
public OrderItem(String productName, int quantity) {
this.productName = productName;
this.quantity = quantity;
}
public String getProductName() {
return productName;
}
public int getQuantity() {
return quantity;
}
}
Repository
public interface OrderRepository {
void save(Order order);
Order findById(Long orderId);
}
DDD의 장점
비즈니스 요구사항에 적합한 설계
코드가 비즈니스 로직을 충실히 반영하므로, 도메인 전문가와의 협력이 쉬워진다.
변화에 유연한 구조
도메인을 중심으로 설계하므로, 요구사항 변경에 더 유연하게 대응할 수 있다.
높은 가독성과 유지보수성
유비쿼터스 언어를 사용하기때문에, 코드가 자연스럽게 비즈니스 요구사항을 표현한다.
DDD는 단순히 기술적인 접근 방법이 아니라, 비즈니스 문제를 해결하기 위한 사고방식의 변화라고 느꼈다. 처음에는 애그리게이트 같은 용어와 개념이 낯설었지만, 코드를 구현해면서 "왜 이렇게 설계해야 하는지"를 조금씩 이해할 수 있었다.특히, 비즈니스 요구사항을 코드에 녹여내는 과정이 재밌었다. Order라는 개념이 단순히 데이터를 저장하는 것이 아니라, 비즈니스 로직을 포함한 하나의 모델로 설계되는 점이 흥미로웠다. 이전에 작성했던 도메인 개념 관련 개발일지에서는 도메인이라는 단어를 이해하는 데 집중했다면, 이번에는 그 개념을 설계 철학으로 확장한 학습경험을 기록하게 되었다. 아직 어렵지만, DDD의 철학과 개념을 더 깊이 이해하고싶다.
'개발Article' 카테고리의 다른 글
[TIL]20241217 Observability (2) | 2024.12.17 |
---|---|
[TIL]20241216 벨루가 추천 시스템 (1) | 2024.12.16 |
[TIL]20241214 내 시각에서 이해한 클러스터링 개념 (0) | 2024.12.14 |
[TIL]20241213 유닛테스트와 통합테스트의 경계 (2) | 2024.12.13 |
[TIL]20241212 모든 샤드 클래스의 갱신 요청 처리 설계 (0) | 2024.12.12 |