DDD와 CQRS

[tco0427]

스프린트2 기간 동안 계속해서 고민해온

• DB 테이블과 JPA Entity 매핑 방식에 대한 고민
• 패키지명(Controller, Service, Domain)에 대한 고민
• 명령 과 조회 의 분리 (CQRS) 에 대한 고민

의 종지부(?)를 찍고 우리 팀의 방향성을 확실하게 잡아줄 수 있겠다 라는 생각이 드는 글을 읽게 되어 팀원들과 공유하려고 합니다.

---

우리팀은 어떻게 DB 테이블과 JPA Entity 매핑을 할지에 대해서 꽤나 긴 시간 동안 고민하였다.
가장 먼저 다대다 관계에서 ORM 이라는 관점에서도 테이블 구조(ex. study_tag)를 그대로 객체 관계로 가져오는 것은 Object 와 Relation을 적절히 Mapping 하는 것이 아니므로 옳지 않다는 데에 모두 동의하였다.
그런데 일대다나 일대일은 어떻게 할 것인가에서는 조금 의견이 일치하지 않는 모습을 보였던 것으로 기억한다.🥲
(개인적으로는 이번에 스터디 후기 조회 를 구현하면서도 객체끼리의 매핑, 혹은 객체 관계로 생각하기 보다는 어떻게 조회를 편리하게 할까? 에 초점을 맞춰 생각하고 구현을 하니 구조가 훨씬 깔끔하다는 느낌도 받았다. 예를 들어 Study에서 후기를 가지고 있고, 이를 조회한다. 라고 생각하기 보다, 후기 자체가 하나의 별도의 도메인이고 studyId를 가진다.(API도 별도로 호출하여 조회하고 있음))

또한 명령과 조회는 왜 구분해야 하는가? 라는 것에 대해서도 명확한 이유를 찾지는 못한 느낌이 들었던 것이 사실이다. 물론 실제로 작업을 하면서 조회를 위한 로직이 굉장히 복잡하여 향후 구현해야할 CUD와는 구분했으면 하는 느낌이 들기는 했다.

마지막으로 긴 시간 고민한 것은 아니지만 패키지명을 어떻게 할 것인가에 대해서도 이야기가 나왔었다.

---

이러한 모든 내용이 DDD(Domain Driven Desin) 이라는 글에 함축적으로 모두 정리되어 있었다. (갈증이 해소된 느낌이었다. 물론 이 글을 읽는다고 모든 내용을 구체적으로 알기는 쉽지 않으나, 이 포스팅 하나에 우리의 여러 고민 내용이 내포되어 있어 신기했다.)

DDD에 대해서 공부해본 적이 없고, 크게 관심을 가져보지 못해서 잘은 모르지만, 해당 글을 읽고 나서 현재 우리의 프로젝트를 보면 DDD를 하고 있는 것이 아닌가? 하는 생각이 든다.
DDD에서 사용하는 도메인, 도메인 모델, 엔티티, 벨류 오브젝트 등과 같은 용어도 우리의 의미와 동일하며, 현재 우리가 나눈 패키지의 구조 등을 보아도 도메인 그 자체와 도메인 로직에 초점을 맞추는 DDD의 특징과도 일치하는 것 같다는 생각이 든다.
특히 오늘 회고에서 많이 나온 사용자 스토리 포인트 활동도 DDD에서 이야기하는 이벤트 스토밍 과정과도 굉장히 유사하다.

따라서 우리가 이번 프로젝트의 어떤 하나의 작은 목표로서 우리 나름대로의 DDD 를 지켜본다. 라는 것을 세워보아도 괜찮겠다? 라는 생각이 들었다.
가장 먼저 패키지에 대해서는 도메인 주도 설계 아키텍쳐에 따라서 다음과 같이 정리해볼 수도 있겠다.

• Presentation 레이어 : UI 영역이라고 사용하는데도 있으며 사용자의 요청을 받아 애플리케이션 영역의 처리 결과를 다시 사용자에게 반환 하는 역할을 한다.
• Application 레이어 : 사용자에게 제공해야 할 기능을 구현한다.
• Domain 레이어 : 도메인 모델을 구현한다. 한 애그리게이트에 넣기 애매한 도메인 개념을 구현하려면 애그리게이트에 억지로 넣기보다는 도메인 서비스를 이용해서 도메인 개념을 명시적으로 드러내면 된다. 도메인 서비스를 사용하는 주체는 애그리게이트가 될 수 있고 응용 서비스가 될 수도 있다.
• Infrastructure 레이어 : 영속성을 구현하거나 외부와 통신하는 기능을 제공하는 레이어이다.

다음으로는 CQRS(명령 및 쿼리 책임 분리) 이다.

객체 지향으로 도메인 모델을 구현할 때 주로 사용하는 ORM 기법은 도메인의 상태 변경을 구현하는 데는 적합하지만, 여러 애그리거트에서 데이터를 가져와 출력하는 기능을 구현하기에는 고려할 것들이 많아서 구현을 복잡하게 만드는 원인이 된다.

라는 말이 가장 중요한 것 같다. 현재 우리 서비스 레이어에서의 조회 로직의 복잡함(태그를 통한 스터디 필터링 등) 뿐 아니라 스터디 개설 부분 구현에서 발생한 side effect 인 도메인의 변화가 DTO 등과 같은 곳에 영향을 미치는 것을 방지할 수 있다는 베루스의 말과도 일맥상통하는 부분인 것 같다.

그리고 이러한 구현 복잡도를 낮추는 간단한 방법이 있는데 바로 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것이다.

하지만 CQRS의 장단점을 확실히 집고 넘어가면 좋겠다.

• 명령 모델을 구현할 때 도메인 자체에 집중 가능하다.

• 조회 성능을 향상시키는데 유리하다.
  -> 쿼리문을 최적화하는데 유리할 것 같다. (단순 JPA 에서 fetch join 등의 방법 보다..)

• 구현해야 할 코드가 더 많다.
  -> 초기 개발 비용이 높은 대신 유지보수 비용이 적다면?? -> 충분히 사용할만한 가치가 있음

• 더 많은 구현 기술이 필요하다.
  -> (링크를 건 글에서 어떤 구현 기술이 필요하다? 라고 명시가 되어 있지 않아서 공감이 되지 않는 내용임)

그리고 이렇게 명령과 조회를 분리한다고 하면 식별자를 통한 매핑이 훨씬 수월할 것이다.
(DDD의 핵심 목표인 Lossly coupling을 위해서라도)

---

만약 이 Discussion을 읽고, DDD 가 궁금하면(저도 잘 몰라서...😅) 함께 공부해보고 또 다른 Discussion이나 댓글로 공유하는 것도 좋을 것 같습니다.
또한 잘못된 부분이나 공감되는 부분(혹은 공감되지 않는 부분)을 댓글로 공유해주면 좋을 것 같습니다..!!

[verus-j]

디우의 의견에 공감합니다. 저도 DDD에 대해서 잘 모르지만... 여태까지 개인적으로 웹 애플리케이션을 만들면서 느꼈던 점은 명령과 조회의 관심사와 변경점이 서로 달라 같은 모델에서 처리할 때 점점 리팩토링하기 힘들었습니다. 그러다보니 조금씩 타협해가는 상황이 많이 펼쳐졌습니다. 이후, 레벨 2때 명령과 조회를 분리시켜보았는데, 명령이나 조회에 변경점이 생겼을 때 서로에게 영향을 주지 않아 편하게 리팩토링할 수 있었습니다. 그래서, 이번 팀 미션에서도 이 방법을 추천한겁니다 ㅎㅎ
이번 주말동안 명령과 조회를 분리하는 리팩토링을 하면서 느낀 점은 조회를 할 때 Data라는 이름을 가진 클래스(즉, 조회를 위한 모델)를 따로 만들어 관리하면 어떨까합니다. 이 부분은 월요일날 한번 얘기를 나눠보시죠~

[tco0427]

DDD에 관한 책을 하나 사서 잠실 캠퍼스에 하나 두려고 합니다..!! 깊이 있게 공부하기 보다 필요한 부분을 보면서 우리 프로젝트에 적절히 적용해보아도 좋을 것 같습니다..!!

[jaejae-yoo]

저도 DDD와 CQRS에 대해 아직 잘 모르지만, 디우가 공유해 준 글과 베루스가 공유해 준 의견에서 배울 수 있었네요!

아직 해당 개념에 익숙한 건 아니지만 그동안 구현하거나 다른 팀원들의 코드를 보며 느낀 점을 공유해 보자면,
명령과 쿼리의 목적과 특징이 꽤 다르다는 것이었습니다.
명령(CUD)는 보통 하나의 테이블에서 변경할 데이터들을 업데이트하는 반면,
대다수의 조회(R)는 한 테이블이 아닌 여러 테이블이 엮어야 원하는 데이터를 가지고 올 수가 있었습니다.

둘의 다른 점을 인지하니, 둘을 분리하지 않고 구현하면 그 과정에서 eager? lazy? 등의 신경 써야 할 부분이 많아질 수 있다는 관점에서 바라볼 수 있었네요.

더불어 저 또한 같은 의견으로, 여러 관점에서 장단점을 고민해 보면 좋을 것 같습니다.
지난 토론에서 값 객체인 Id로 관계를 맺는 것이 객체 지향적인가에 대해 이야기를 나눴었는데, 트레이드 오프가 있었던 것 같습니다.

추가적으로 해당 방법으로 해보면서 객체지향에 대해 더 고민해 볼 수도 있었던 것 같아요.
다른 값 객체가 특정 엔티티의 필드로 있을 때 종속적인 느낌이 든다는 생각 및 구현 방법이 자연스러운지에 대해서도 고민해 볼 수 있었네요.

아직 부족한 부분이 많아서, 계속 공부하고 고민하며 구현해야겠네요!
좋은 의견과 글 감사합니다.