[책 리뷰] 도메인 주도 개발 시작하기

'XXX를 어떤 단위로 분리하지?' 와 같은 자문을 프로젝트를 진행하면서 많이 했었다. XXX는 프로젝트가 될 수도, 패키지가 될 수도, 도메인, 클래스가 될 수 있는데 대게 도메인 모델과 작성한 클래스를 어떤 기준으로 분리할지에 대해 자주 고민했던 것 같다.

 

마침 팀에서 진행하는 스터디에서 평소에도 읽어보고 싶던 DDD 관련 책을 읽는다고 해서 참여하게 됐고, 약 2달에 걸쳐 책을 읽은 내용을 정리해 보고자 한다.

 

먼저 최범균님의 '도메인 주도 개발 시작하기' 책은 개발을 시작한지 얼마되지 않은 나도 이해하기 쉬울 정도로 가벼운 예제 + 자세한 설명을 제시한다. 특히, Java 베이스의 Spring과 JPA를 함께 사용하는 개발자들이 이해하기 쉬운 예제들을 많이 포함하고 있다.

 

책에서는 OOP를 중심으로 도메인 모델을 논리적으로 어떻게 분리할 것인가에 대한 이야기를 하는데 중간 중간 트랜잭션 설계, 이벤트, CQRS 등 현실적인 관점에서 기술을 어떻게 도입할지에 대한 내용도 나온다.

 

책을 읽으면서 XXX 주도 개발에 대한 회의적인 시선도 많다는 것을 동시에 알 수 있었는데, 개인적으로는 개발서를 읽는 목적이 무조건 개발서의 내용을 프로젝트에 적용하겠다는 것보다는 여러 관점이 나온 배경에 대해 알아본다? 는 생각으로 접근하면 좋지 않을까 하는 생각을 하고 있다.

 

---

짧은 정리

(내가 생각하는) OOP 베이스의 개발론은 변경에 대응하기 쉬운 코드를 작성하는 법을 그 근간으로 하고 있다고 생각한다. DDD에서는 변경에 대응하는 방법을 설명하기 위해 크게 애그리거트, 바운디드 컨텍스트와 그 내부에 존재하는 도메인 모델 설계 방법을 제시한다.

 

애그리거트와 도메인 모델 그리고 바운디드 컨텍스트

이 세가지는 모두 논리적인 개념이기 때문에 책을 읽지 않으면 굉장히 모호한 개념처럼 느껴질 것이라 생각한다.

 

내가 책에서 읽은 내용 중 잘 와닿았던 것은 하나의 애그리거트는 라이프사이클이 거의 동일한 객체들의 집합으로 구성된다는 것이고(역은 성립하지 않는다) 보통 두 개 이상의 엔티티(또는 디스크에 저장되는 데이터의 단위)는 라이프 사이클이 다르기 때문에 애그리거트는 하나의 엔티티로 바라보면 되지 않을까? 하는 생각을 하고 있다.

 

도메인 모델은 하나의 애그리거트를 구성하는 객체다. 애그리거트를 구성하는 데이터는 굉장히 많을 수 있는데 그 중에서도 응집성 높은 데이터와 메소드의 집합을 하나의 도메인 모델로 묶을 수 있겠다. 따라서 애그리거트는 하나 이상의 도메인 모델을 포함한다.

 

바운디드 컨텍스트는 서로 다른 문맥을 구분짓는 개념이다. 가령 상품 주문 영역(보통 개발을 담당하는 팀 혹은 사람)에서 상품 번호를 itemNo로 표현한다면 쿠폰 발행 영역에서는 targetNo로 표현하는 등 개발 문맥에 맞게 모델을 변경할 수 있음을 의미한다. 물론 이러한 문맥을 전환시켜줄 장치가 필요한데 책에서는 이를 ACL(Anti Corruption Layer)과 OHS(Open Host Service) 으로 설명한다.

 

도메인 서비스

1. 서비스 레이어에서는 도메인 로직을 포함하지 말고 애그리거트를 호출하는 형태로 표현

2. 서비스에서는 트랜잭션과 같은 더 상위 개념을 표현

 

위 두 가지 조건을 충족시키기 위해 여러 애그리거트와 상호작용 하는 코드를 하나의 도메인 서비스 내에서 로직을 표현한다.

 

그걸 서비스에서 하면 되지 왜 도메인 서비스를 따로 만들어? 에 대한 내 생각은 역시 관심사의 분리라고 생각한다. 트랜잭션과 같은 지식을 포함하지 않는 순수한 도메인 로직을 도메인 서비스 내부나 도메인 모델 내에 명시함으로써 코드 관리 범위를 더욱 축소시킨다는 관점을 이야기하는 것이라고 생각한다. 충분히 납득 가능하고 구조에 대한 이해만 수반되면 적용하기 좋은 패턴이라고 생각한다.

 

이벤트

책에서 비동기 이벤트에 대한 내용을 다룬다. 간단한 개념을 소개하지만 간단하게 케이스만 정리하자면

1. 로컬 핸들러를 통해 비동기 이벤트(@Async)를 실행하는 것

2. 외부 메시징 시스템 사용

3. 이벤트 저장소를 사용

 

책에서는 각각의 방식마다 대부분 이벤트를 어떻게 효율적으로 처리할 지, 이벤트를 공유하는 법(이벤트 유실을 최소화하는 방법)에 초점을 맞추어 설명한다.

 

CQRS

CQRS는 기본적으로 명령 모델과 조회 모델을 분리해 트랜잭션을 처리하는 것으로 개별 트랜잭션을 효과적으로 처리하기 위해 모든 데이터를 불러오는 것이 아닌 관심 있는 데이터를 조회/제어 하는 방식을 의미한다.

 

책의 마지막 장에 CQRS를 포함한 이유가 뭘까? 생각을 하다 내가 내린 결론은 문맥과 사용 의도에 따라 도메인 모델은 얼마든지 변경될 수 있다는 것이 CQRS의 관점과 유사하기 때문이지 않을까? 하는 생각을 했다.

---

마무리

'도메인 주도 개발 시작하기' 에서는 저자의 말처럼 DDD에 대해 아주 간략하게 설명하는 책임에도 불구하고 느낀바가 상당히 많았다.

 

특히, 트랜잭션과 도메인 로직의 분리에 대해서 한번 더 생각해 볼 필요가 있다고 느꼈고, 성능을 고려한 모델 설계가 가능하다는 것에 대해서도 다시금 상기할 수 있었다.

 

또한, 시스템(레이어) 간의 결합도를 낮추고 변경에 대응 가능한 코드를 작성하는 것의 중요성을 또 다시 느낄 수 있었다.