아카이브

DDD를 처음 접하면 용어가 먼저 보인다. Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event, Bounded Context, Context Map. 여기에 CQRS, Event Sourcing, Hexagonal Architecture, Microservice까지 이어지면 DDD는 거대한 기술 체계처럼 느껴진다.

DDD는 강력한 접근이지만 모든 문제에 필요한 것은 아니다. 복잡한 도메인에는 큰 도움이 되지만, 단순한 CRUD 시스템에 과하게 적용하면 오히려 비용만 늘어날 수 있다.

시스템이 커지면 서비스를 나누고 싶어진다. 주문, 결제, 회원, 알림, 정산을 각각 독립 서비스로 만들면 더 깔끔해질 것 같다. 각 팀이 자신의 서비스를 소유하고, 독립적으로 배포하고, 장애도 격리할 수 있을 것처럼 보인다.

DDD를 공부하다 보면 깨끗한 예제를 많이 보게 된다. 도메인 객체는 선명하고, 계층은 분리되어 있으며, Aggregate 경계도 잘 잡혀 있다. 하지만 현실의 시스템은 그렇지 않은 경우가 많다.

테스트는 보통 버그를 막기 위한 도구로 여겨진다. 물론 맞는 말이다. 테스트는 코드가 기대한 대로 동작하는지 확인하고, 변경이 기존 기능을 깨뜨리지 않도록 돕는다.

DDD를 이야기하면 마이크로서비스가 함께 등장하는 경우가 많다. Bounded Context를 나누고, 각 컨텍스트를 서비스로 만들고, 독립 배포와 독립 데이터베이스를 갖추는 그림은 매력적이다.

Domain Event를 배우고 나면 자연스럽게 Event Sourcing을 만나게 된다. 도메인에서 일어난 일을 이벤트로 표현한다면, 아예 상태가 아니라 이벤트를 저장하는 것이 더 좋은 것처럼 보인다.

DDD를 공부하다 보면 CQRS라는 단어를 자주 만나게 된다. 그래서 DDD를 제대로 하려면 CQRS를 해야 하고, CQRS를 하려면 이벤트 소싱까지 해야 한다고 생각하기 쉽다.

소프트웨어에서 일관성은 중요하다. 주문이 생성되었는데 결제 정보가 없거나, 구독이 갱신되었는데 이용 권한이 부여되지 않거나, 환불이 완료되었는데 정산 금액이 그대로라면 문제가 된다.

Java와 Spring 환경에서 DDD를 이야기하면 거의 반드시 JPA 이야기를 만나게 된다. Entity라는 단어가 겹치기 때문이다. JPA에도 Entity가 있고, DDD에도 Entity가 있다. 그래서 많은 팀이 자연스럽게 JPA Entity를 도메인 모델로 사용한다.

계층형 아키텍처는 도메인 모델을 보호하기 위한 중요한 출발점이다. 하지만 실제 코드에서는 계층이 한 방향으로만 흐르는 것처럼 보이면서도, 도메인이 여전히 프레임워크나 데이터베이스에 강하게 묶이는 경우가 많다.

DDD를 구현하려고 하면 곧 아키텍처 이야기를 만나게 된다. Presentation Layer, Application Layer, Domain Layer, Infrastructure Layer 같은 이름이 등장한다. 패키지를 나누고, 의존성 방향을 정하고, 각 계층의 책임을 구분한다.

도메인 로직은 처음에는 작은 조건문으로 시작한다. 특정 상태이면 처리하지 않고, 특정 날짜가 지나면 만료시키고, 특정 요금제이면 할인하지 않는다. 처음에는 if 몇 개면 충분하다.

객체 생성은 종종 단순한 기술 문제처럼 여겨진다. 생성자를 호출하고, 필요한 값을 넣고, 필드를 채우면 끝이라고 생각하기 쉽다. 하지만 도메인 모델에서는 생성도 중요한 행위일 수 있다.

DDD를 공부하면 “도메인 로직은 도메인 객체 안에 있어야 한다”는 말을 자주 듣는다. 이 말은 중요하다. 도메인 규칙이 Application Service나 Controller에 흩어지면 모델은 빈약해진다.

DDD를 적용할 때 가장 혼란스러운 이름 중 하나가 Service다. Application Service, Domain Service, Infrastructure Service가 모두 Service라는 이름을 갖는다. 그래서 시간이 지나면 모든 로직이 SomethingService에 모인다.

DDD에서 Repository는 자주 오해되는 패턴이다. 많은 코드에서 Repository는 사실상 DAO처럼 사용된다. 데이터베이스에서 데이터를 조회하고, 특정 컬럼을 수정하고, 필요한 쿼리를 실행하는 객체가 Repository라는 이름을 갖는다.

DDD를 적용한다고 말하면서도 실제 코드를 보면 도메인 객체가 거의 아무 일도 하지 않는 경우가 많다. 클래스 이름은 Subscription, Order, Payment처럼 도메인스럽지만, 내부에는 필드와 getter, setter만 있다. 중요한 규칙은 대부분 SubscriptionService, OrderService, PaymentService 같은 서비스 클래스에 들어 있다.

Value Object는 값으로 식별된다. 10,000원은 10,000원이고, 같은 시작일과 종료일을 가진 기간은 같은 기간이다. 중요한 것은 그 값 자체다.

DDD의 전술적 패턴을 떠올리면 많은 사람이 Entity부터 생각한다. 식별자, 생명주기, 상태 변화가 있는 객체는 분명 중요하다. 하지만 실제 코드에서 도메인 의미를 가장 작고 선명하게 드러내는 출발점은 Value Object일 때가 많다.

좋은 도메인 모델을 만드는 일은 어렵다. 도메인 전문가와 대화하고, 유비쿼터스 언어를 다듬고, Bounded Context를 나누고, Aggregate 경계를 고민해야 한다. 그런데 어렵게 만든 모델도 쉽게 망가질 수 있다.

Bounded Context를 이해하면 모델을 하나로 합치려는 욕심을 내려놓게 된다. 같은 단어라도 맥락에 따라 다른 의미를 가질 수 있고, 하나의 거대한 모델보다 여러 개의 일관된 모델이 더 나을 수 있다는 사실을 받아들이게 된다.

DDD를 공부하다 보면 좋은 설계를 모든 곳에 적용하고 싶어진다. Entity를 만들고, Value Object를 만들고, Aggregate를 나누고, Repository와 Domain Service를 세운다. 도메인 이벤트도 발행하고, 계층도 깔끔하게 분리한다.

DDD를 공부하고 나면 설계가 더 좋아질 것처럼 느껴진다. Entity, Value Object, Aggregate, Repository, Domain Event 같은 개념을 익히고 나면 복잡한 비즈니스 로직도 깔끔하게 정리될 것 같다.

도메인 모델은 상태만으로 이루어져 있지 않다. 도메인에서는 계속 어떤 일이 일어난다. 주문이 접수되고, 결제가 완료되고, 배송이 요청되고, 구독이 갱신되고, 환불이 승인되고, 이용 권한이 만료된다.

DDD의 전술적 패턴 중에서 가장 중요하면서도 가장 많이 오해되는 개념이 Aggregate다. Entity와 Value Object는 비교적 직관적으로 받아들이기 쉽다. 하지만 Aggregate는 처음 접하면 애매하다.

DDD에서 가장 중요한 개념을 하나만 고르라면 많은 사람이 Bounded Context를 이야기할 것이다. 그런데 동시에 가장 많이 오해되는 개념이기도 하다.

DDD에서 가장 중요하면서도 가장 쉽게 가볍게 다뤄지는 개념이 유비쿼터스 언어다. 많은 팀이 유비쿼터스 언어를 “용어집을 만드는 일” 정도로 이해한다. 물론 용어를 정리하는 것은 좋은 시작이다. 하지만 유비쿼터스 언어는 용어집보다 훨씬 더 깊은 개념이다.

DDD를 이해하려면 먼저 “모델”이라는 말을 다시 생각해야 한다. 많은 사람이 모델을 현실을 최대한 정확하게 옮긴 것이라고 생각한다. 현실에 회원이 있으니 Member를 만들고, 주문이 있으니 Order를 만들고, 결제가 있으니 Payment를 만든다. 현실에 있는 속성은 되도록 빠짐없이 담으려 한다.

DDD를 처음 공부하면 자연스럽게 기술적인 단어들이 먼저 눈에 들어온다. Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event. 조금 더 나아가면 Layered Architecture, Hexagonal Architecture, CQRS, Event Sourcing 같은 단어들이 따라온다.