DDD를 처음 접하면 개념이 너무 많아서 길을 잃기 쉽다. 바운디드 컨텍스트, 애그리거트, 유비쿼터스 언어, Facade, DTO... 각각은 이해했는데 전체 그림이 안 보이는 느낌.
그런데 찬찬히 들여다보면, 이 모든 개념이 결국 하나의 목표를 향하고 있다는 걸 알게 된다.
비즈니스 규칙을 코드로 정확하게 표현하고, 그것이 시스템 전체에서 일관되게 동작하게 한다.
이 한 문장이 DDD의 본질이다.
일관성이 왜 그렇게 중요한가
코드가 커질수록 반드시 이런 일이 생긴다.
OrderService → 주문 수량 검증 로직 있음
CartService → 주문 수량 검증 로직 없음
AdminService → 주문 수량 검증 로직 다르게 구현됨같은 비즈니스 규칙인데 세 곳이 다르게 동작한다. 나중에 규칙이 바뀌면 세 곳을 다 찾아서 고쳐야 한다. 하나라도 빠뜨리면 버그가 된다.
DDD가 말하는 것은 이것이다.
비즈니스 규칙은 도메인 안에 단 한 곳에만 존재해야 한다.이걸 달성하면 생기는 것
규칙이 바뀔 때 한 곳만 고치면 된다
// Order 도메인 안에 단 한 번만 정의된다
public void validateQuantity(int quantity) {
// 비즈니스 규칙이 바뀌면 이 한 곳만 수정하면 된다
if (quantity > MAX_ORDER_ITEMS) {
throw new IllegalArgumentException("최대 10개까지 주문 가능합니다.");
}
}
// OrderService, CartService, AdminService
// 어디서 호출하든 동일한 규칙이 적용된다
// 흩어진 검증 로직이 없다코드가 비즈니스 문서가 된다
order.confirm(); // 주문을 확정한다
order.cancel(); // 주문을 취소한다
order.changeQuantity(); // 수량을 변경한다코드만 봐도 비즈니스 흐름이 읽힌다. 기획서 없이도 도메인 코드가 곧 명세서가 된다. 개발자와 기획자가 같은 언어로 소통할 수 있게 되는 것이다. DDD에서 이를 유비쿼터스 언어(Ubiquitous Language)라고 부른다.
DDD의 모든 개념은 이 목표를 향한다
처음엔 파편처럼 보이던 개념들이 사실 하나의 흐름이었다.
비즈니스 문제를 정의하고 → 도메인 식별
경계를 나누고 → 바운디드 컨텍스트
관련 객체를 묶고 → 애그리거트
규칙을 한 곳에 모으고 → 애그리거트 루트
외부에 알 필요 없는 건 숨기고 → 캡슐화
전체에서 일관성을 유지한다 → 유비쿼터스 언어 + 불변식각 개념의 이름이 중요한 게 아니다. 이것들이 전부 "비즈니스 규칙을 코드로 정확하게 표현하고, 일관되게 유지한다" 는 하나의 목표를 위한 도구라는 점이 중요하다.
DDD가 어려운 진짜 이유
기술이 어려운 게 아니다. JPA나 Spring은 사용법이 있고 정답이 있다. 반면 DDD는 정답이 없는 비즈니스 문제를 다룬다.
JPA를 배운다 → 사용법이 있다, 정답이 있다
DDD를 배운다 → 사고방식을 훈련한다, 정답이 없다그래서 DDD를 잘한다는 것은 패턴을 얼마나 많이 아느냐가 아니라, 비즈니스를 얼마나 깊이 이해하고 코드로 표현할 수 있느냐에 달려 있다.
시니어 개발자가 주니어와 가장 크게 차이나는 지점이 바로 여기다. 코드를 짜는 속도나 문법이 아니라, 비즈니스 문제를 구조화하는 능력이다.
DDD가 어려운 이유는, 코드보다 먼저 “이 비즈니스가 왜 이렇게 동작해야 하는가”를
설명할 수 있어야 하기 때문이다.
마치며
DDD를 공부하면서 느끼는 것은, 결국 좋은 코드란 비즈니스를 닮은 코드라는 것이다.
비즈니스가 바뀌면 코드도 자연스럽게 따라갈 수 있어야 한다. 그 유연함을 만들어내는 것이 DDD가 지향하는 방향이다.
아직 모든 걸 완벽하게 적용하기는 어렵다. 하지만 코드를 짤 때 한 번씩 이 질문을 던져보는 것만으로도 달라진다.
이 비즈니스 규칙은 지금 어디에 있는가? 그리고 그것이 일관되게 적용되고 있는가?
