[DDD] chapter 11

Chapter 11

11.1 단일 모델의 단점

주문 내역 조회 기능을 구현하려면 여러 애그리거트에서데이터를 가져와야 한다. Order에서 주문 정보를 가져와야 하고, Product에서 상품 이름을 가져와야 하고, Member에서 회원 이름과 ID를 가져와야 한다.

 

이러한 구현 복잡도 문제를 해결하려면 상태 변경을 위한 모델과 조회를 위한 모델을 분리하여 구현할 수 있다.

11.2 CQRS

Command Query Responsibility Segregation의 약자로 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다.

---

---

CQRS는 도메인이 복잡할수록 명령 기능과 조회 기능이 다루는 데이터 범위에 차이가난다.

 

CQRS를 사용하면 각 모델에 맞는 구현 기술을 선택할 수 있다. 명령 모델은 객체 지향에 기반한 JPA를 사용해서 구현하고, 조회 모델은 DB 테이블에서 SQL로 데이터를 조회할 때 좋은 MyBatis를 사용해서 구현하면 된다.

---

---

이 예시에서는 데이터에 관한 로직에서 Event Handler를 사용한다. 또한 명령 모델과 조회 로직이 다른 Data structure를 사용하는 것을 볼 수 있다. 조회는 역시 MongoDB를 사용해야 하는 것인가 싶다...

 

(그렇다면 결국 조회 서비스까지 다시 빼놔야 하는 것인가...? 인프라 팀이 죽어 나가겠구만...)

11.2.1 웹과 CQRS

일반적인 웹 서비스는 상태를 변경하는 요청보다 상태를 조회하는 요청이 훨씬 많다.

 

대규모 트래픽이 발생하는 웹 서비스는 알게 모르게 CQRS를 적용하게 된다. 단지 명시적으로 명령 모델과 조회 모델을 구분하지 않을 뿐이다. 조회 속도를 높이기 위해 별도 처리를 하고 있다면 명시적으로 명령 모델과 조회 모델을 구분한다.

11.2.2 CQRS 장단점

CQRS 패턴을 적용할 때 얻을 수 있는 장점은 명령 모델을 구현할 때 도메인 자체에 집중할 수 있다는 점이다. 성능에 대한 부담이 덜한 상태로 작성할 수 있어 복잡도 또한 사라진다.

 

단점은 구현해야 할 코드가 너무 많아 진다는 것이다. 도메인이 단순하거나 트래픽이 그렇게 많은 서비스가 아니라면 조회 전용 모델을 따로 만들 때 얻을 이점이 있는지 따져봐야 한다.