[개념 정리] CQRS란? CommandService와 QueryService로 분리하는 이유

▶︎ CQRS란?

---

CQRS는
Command and Query Responsibility Segregation 의 약자로
Command와 Query의 책임을 분리하는 디자인 패턴이다.

Command : 데이터베이스를 변경하는 모든 작업. → Create, Update, Delete

Query : 데이터베이스에서 데이터를 조회하는 모든 작업. → Read → 상태 변경 X

 
 
 
 
 
 

▷ 서비스를 분리하는 이유

---

위 CQRS 디자인패턴을 바탕으로 서비스를 분리하면
각각의 서비스가 하나의 책임만을 가지게 되어
코드의 유지보수성 향상, 성능 최적화, 확장성 측면에서 이점이 있다.
어떻게 성능 최적화를 할까?
위 말 그대로 QueryService와 CommandService를 분리함으로써 성능 최적화를 불러올 수 있다.
 
 
 
 
 

▶︎ Command Service Layer

---

Insert, Update 또는 Delete와 같이 DB와 통신 후, 응답 값이 존재하지 않는 요청들을 관리하는 Service Layer
 
 
 
 

▷ Command Service Layer를 분리하는 이유

---

읽기 전용 트랜잭션을 사용하는 Query 메서드와는 다르게 트랜잭션이 필요한 Update 또는 Delete, Insert등의 데이터 변경 로직을 관리하기 위해 @Transactional 어노테이션에 readOnly = true 옵션을 붙이지 않은 체로 사용함
 
 
 
 
 
 

▶︎ Query Service Layer

---

select 구문과 같이 DB 통신을 통해 데이터를 조회하는 요청들을 관리하는 서비스계층.
Only, 데이터가 어떤 값인지 확인하기 위한 조회 시에 사용
 
 
 

▷ Query Service Layer를 분리하는 이유

---

• 읽기 전용 트랜잭션 사용
  • 해당 Service Layer의 메서드는 오직 데이터가 어떤 값인지 조회하는 용도이다.
  • 때문에, 더티체킹이 필요 없으므로 readOnly = true 를 사용한다.
• 성능 향상
  • 트랜잭션을 읽기 전용 모드로 사용하기 때문에 영속성 컨텍스트가 관리하지만 flush 를 하지 않는다.
  • 플러시를 하지 않기때문에 더티체킹과 같은 무거운 작업을 수행하지 않으므로 성능이 향상된다.

 
 
 
 
 
 

▶︎ 내 생각

---

분리하는 이유에 대한 내 생각은 이러하다.

1. 유지보수에 큰 이점이 있다.
   • 서비스 메서드가 많아졌을 때, 각 메서드의 역할이 명확히 분리되어 있으면 변경 관리와 버그 수정을 더 쉽게 할 수 있다.
2. 확장성이 좋다.
   • 시스템이 복잡해지면 각 레이어를 독립적으로 확장할 수 있다.
3. 각 메서드의 역할이 명확해진다.
   • Query Service 안에 있는 메서드는 조회만, Command Service 안에 있는 메서드는 데이터 변경 작업만 수행한다는 것을 명확히 알 수 있다.
   • 이는 코드의 가독성을 높이고, 각 메서드의 역할을 명확히함.

우선 내 생각은 뭐 성능 최적화? 그 이유때문은 아닌 것 같다.
그 이유라면 그냥 한 곳에 때려넣고 메서드위에 트랜잭션 옵션을 붙여주면 된다.
 
내 생각에 분리하는 이유는
이후에 서비스 메서드가 많아졌을 때, 유지보수하기 편하라고 분리해놓는다고 생각한다.
또한 코드 명확성, 즉 Query Service안에 있는 메서드들은 조회만 하는 메서드! 를 명확하게 알 수 있는 이유도 있을 것 같다.
추가로 확장성인데, 시스템이 복잡해지면 요구사항에 맞게 독립적으로 확장할 수 있다.
 
예를 들어, 조회 성능을 향상시키기 위해 캐싱을 도입한다고 해보면 Query Service 레이어에서만 캐싱 로직을 추가하면 된다.
이렇게 하면 조회 성능을 최적화 하면서도 데이터 일관성을 유지할 수 있다.